Zum Hauptinhalt springen

Mock Full 02 — 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 Legacy-Modul wird auf Spring migriert. Das Team will, dass der Container Abhängigkeiten liefert statt manueller new-Aufrufe in Business-Klassen.

Was ist der primäre Mechanismus, mit dem Spring eine PaymentGateway-Implementierung in OrderService liefert?


@Service
public class OrderService {
  private final PaymentGateway paymentGateway;
  public OrderService(PaymentGateway paymentGateway) {
    this.paymentGateway = paymentGateway;
  }
}
  • A) Dependency Injection — der Container löst Collaborators auf und liefert sie bei Erstellung oder Injection
  • B) Aspect-Oriented Programming — Cross-Cutting Advice verdrahtet Collaborators automatisch
  • C) Component Scanning — Scanning allein erzeugt und injiziert Abhängigkeiten ohne Bean-Definitionen
  • D) Property Binding — @Value ersetzt Konstruktor-Verdrahtung für alle Service-Abhängigkeiten
Antwort & Erklärung

Richtige Antwort: A

Springs IoC-Container verwaltet Objekterzeugung und Verdrahtung. Dependency Injection ist, wie Collaborators bereitgestellt werden (Konstruktor, Setter oder Feld). AOP handhabt Cross-Cutting Concerns; Scanning findet Beans, aber Injection ist der Liefermechanismus.

Warum die anderen Optionen falsch sind:

  • B) AOP fügt Verhalten um Methoden hinzu; es ersetzt nicht DI für zentrale Collaborators.
  • C) Component Scanning findet @Component-Klassen, aber Injection liefert weiterhin Abhängigkeiten.
  • D) @Value injiziert skalare Konfiguration, nicht beliebige Service-Collaborators als primäres Wiring-Modell.

Merksatz: „IoC erzeugt und besitzt Beans; DI ist, wie diese Beans ihre Abhängigkeiten erhalten."

Weiterlernen: Buchkapitel

Frage 2​

Zwei Beans hängen voneinander ab: ReportGenerator braucht AuditTrail, und AuditTrail braucht ReportGenerator. Beide nutzen nur Konstruktor-Injection.

Was passiert beim Start des ApplicationContext?


@Service
public class ReportGenerator {
  public ReportGenerator(AuditTrail auditTrail) { ... }
}

@Service
public class AuditTrail {
  public AuditTrail(ReportGenerator reportGenerator) { ... }
}
  • A) Spring erzeugt beide Beans lazy bei erster Nutzung und löst den Zyklus zur Laufzeit
  • B) Spring injiziert null in einen Konstruktor und schließt die Verdrahtung ab, nachdem beide existieren
  • C) Context-Startup schlägt fehl, weil kein Bean ohne den anderen konstruiert werden kann
  • D) Spring wechselt automatisch eine Seite auf Setter-Injection, um den Zyklus zu brechen
Antwort & Erklärung

Richtige Antwort: C

Rein konstruktorbasierte zirkuläre Abhängigkeiten sind nicht erfüllbar: Jeder Bean braucht den anderen vollständig konstruiert. Spring schlägt beim Context-Refresh fail-fast fehl. Setter/Feld-Injection oder @Lazy auf einem Konstruktorparameter kann den Zyklus brechen.

Warum die anderen Optionen falsch sind:

  • A) Lazy Initialization verzögert Erzeugung, löst aber gegenseitige Konstruktorabhängigkeit beim ersten Zugriff nicht.
  • B) Spring injiziert kein null, um Konstruktorzyklen zu brechen.
  • D) Spring konvertiert Konstruktor-Injection nicht still zu Setter-Injection.

Merksatz: „Konstruktor-Zyklen schlagen beim Startup fehl; brechen mit @Lazy, Redesign oder Setter/Feld-Injection."

Weiterlernen: Buchkapitel

Frage 3​

Ein Team hat drei NotificationSender-Implementierungen als Beans registriert. AlertService muss den namens smsSender nutzen.

Welcher Ansatz wählt den smsSender-Bean zuverlässig zur Injection-Zeit?


@Component("smsSender")
public class SmsNotificationSender implements NotificationSender { }

@Service
public class AlertService {
  // welche Injection ist korrekt?
}
  • A) Bevorzugte Implementierung mit @Primary markieren und NotificationSender ohne Qualifier injizieren
  • B) Mit @Qualifier("smsSender") auf dem Konstruktorparameter (oder Feld/Setter) injizieren
  • C) Das Interface in SmsNotificationSender umbenennen, damit Spring per Typ wählt
  • D) @Autowired auf List<NotificationSender> nutzen und Index 0 nehmen
Antwort & Erklärung

Richtige Antwort: B

@Qualifier("smsSender") disambiguiert, wenn mehrere Beans einen Typ teilen. @Primary markiert einen Default, zielt aber nicht auf einen bestimmten benannten Bean, wenn andere ebenfalls existieren.

Warum die anderen Optionen falsch sind:

  • A) @Primary hilft, wenn ein Default reicht; es garantiert nicht smsSender, wenn mehrere Beans konkurrieren.
  • C) Der Injection-Typ bleibt NotificationSender; Impl-Klasse umbenennen disambiguiert nicht von selbst.
  • D) List-Injection-Reihenfolge ist keine zuverlässige Auswahlstrategie für Produktions-Verdrahtung.

Merksatz: „Mehrere gleichtypige Beans brauchen @Qualifier oder @Primary — Qualifier zielt per Name auf einen bestimmten Bean."

Weiterlernen: Buchkapitel

Frage 4​

Ein Entwickler vergleicht BeanFactory und ApplicationContext für ein CLI-Tool, das schnell starten und wenige Beans initial laden soll.

Welche Aussage über BeanFactory versus ApplicationContext ist korrekt?

  • A) ApplicationContext lädt alle Beans immer lazy; BeanFactory lädt eager
  • B) Beide sind in Enterprise-Apps identisch; die Namen sind historische Aliase
  • C) BeanFactory unterstützt Internationalisierung und Event-Publikation; ApplicationContext nicht
  • D) BeanFactory ist der grundlegende IoC-Container mit lazy-by-default-Verhalten; ApplicationContext fügt Enterprise-Features hinzu und instanziiert Singletons typischerweise eager
Antwort & Erklärung

Richtige Antwort: D

BeanFactory ist der fundamentale Container (lazy Singleton-Erzeugung by default). ApplicationContext erweitert ihn um Message Sources, Events, AOP-Auto-Application und meist eager Singleton-Initialisierung beim Refresh.

Warum die anderen Optionen falsch sind:

  • A) Das Lazy/Eager-Verhalten ist für typische Singleton-Startup-Muster umgekehrt.
  • B) Sie unterscheiden sich in Fähigkeiten und Default-Initialisierungsverhalten.
  • C) Enterprise-Features wie i18n und Events gehören zu ApplicationContext, nicht zur plain BeanFactory.

Merksatz: „BeanFactory = schlanker lazy Kern; ApplicationContext = BeanFactory plus Enterprise-Features und eager Singleton-Warmup."

Weiterlernen: Buchkapitel

Frage 5​

Eine @Configuration-Klasse definiert zwei @Bean-Methoden, wobei der zweite Bean den ersten braucht.

Wie stellt Spring sicher, dass @Bean-Methoden-Inter-Calls innerhalb einer @Configuration-Klasse container-verwaltete Singletons zurückgeben?


@Configuration
public class BillingConfig {
  @Bean
  public TaxCalculator taxCalculator() { return new TaxCalculator(); }

  @Bean
  public InvoiceService invoiceService() {
    return new InvoiceService(taxCalculator());
  }
}
  • A) Spring schreibt Bytecode um, sodass @Bean-Methoden statisch sind und die Configuration-Instanz umgehen
  • B) Spring CGLIB-enhanced die @Configuration-Klasse, sodass @Bean-Methodenaufrufe über den Proxy zum Container routen
  • C) Jeder Aufruf von taxCalculator() erzeugt immer eine neue Instanz, weil new in der Methode steht
  • D) Inter-Bean-Calls funktionieren nur, wenn @Configuration durch @Component ersetzt wird
Antwort & Erklärung

Richtige Antwort: B

Im Full-@Configuration-Modus wird die Klasse geproxyt. taxCalculator() aus invoiceService() aufzurufen geht über den Proxy und liefert den Singleton-Bean aus dem Context, nicht jedes Mal ein frisches new.

Warum die anderen Optionen falsch sind:

  • A) @Bean-Methoden werden nicht statisch gemacht; Proxying fängt Instanzmethodenaufrufe ab.
  • C) Ohne Proxying wäre das wahr; @Configuration-Proxying verhindert doppelte Instanzen.
  • D) @Component mit @Bean-Methoden nutzt Lite Mode ohne volle Inter-Bean-Proxy-Semantik.

Merksatz: „Full @Configuration proxyt @Bean-Methodenaufrufe, damit Inter-Bean-Referenzen singleton-verwaltet bleiben."

Weiterlernen: Buchkapitel

Frage 6​

Eine Bibliothek liefert eine plain Java-Klasse ohne Spring-Annotationen. Die Anwendung muss sie als Bean mit Custom-Initialisierungslogik bereitstellen.

Was ist der idiomatische Weg, LegacyParser als Spring Bean zu registrieren?

  • A) @Component auf LegacyParser setzen, obwohl du den Bibliotheks-Source nicht ändern kannst
  • B) Eine @Bean-Methode in einer @Configuration-Klasse deklarieren, die new LegacyParser() zurückgibt
  • C) LegacyParser in spring.factories legen, damit Component Scanning es aufnimmt
  • D) @Autowired auf einem Feld in LegacyParser nutzen, um sich selbst zu registrieren
Antwort & Erklärung

Richtige Antwort: B

Wenn Source nicht annotierbar ist, registrieren @Bean-Methoden in Java-Konfiguration Third-Party-Typen. Du kontrollierst Instanziierung und kannst @PostConstruct-Wrapper oder Init-Logik in der Factory-Methode ergänzen.

Warum die anderen Optionen falsch sind:

  • A) Du kannst Third-Party-Bibliotheksklassen, die du nicht besitzt, typischerweise nicht annotieren.
  • C) spring.factories ist für Auto-Configuration-Registrierung, nicht allgemeine Third-Party-Bean-Discovery.
  • D) @Autowired registriert keine Beans; es konsumiert bestehende.

Merksatz: „Third-Party-Klassen werden Beans über @Bean-Factory-Methoden in @Configuration."

Weiterlernen: Buchkapitel

Frage 7​

Ein Integrationstest ruft context.refresh() zweimal auf demselben AnnotationConfigApplicationContext auf, ohne ihn zu schließen.

Was ist das erwartete Ergebnis?

  • A) Alle Singleton-Beans werden neu erzeugt und der Context bleibt mit frischen Instanzen nutzbar
  • B) Nur Prototype-Beans refreshen; Singletons bleiben unberührt
  • C) Nur @Lazy-Beans werden beim zweiten Refresh neu erzeugt
  • D) Der zweite refresh() wird still ignoriert
Antwort & Erklärung

Richtige Antwort: A

refresh() fährt den vorherigen Context-State herunter und baut ihn neu auf, wobei Singleton-Bean-Definitionen neu erzeugt werden. Prototype-Instanzen werden nicht als Singletons gespeichert; neue Prototypes entstehen pro Anforderung.

Warum die anderen Optionen falsch sind:

  • B) Singletons werden beim Refresh neu instanziiert, nicht erhalten.
  • C) Refresh baut den Context breit neu auf, nicht nur @Lazy-Beans.
  • D) refresh() ist kein No-Op; es reinitialisiert den Context aktiv.

Merksatz: „refresh() baut den Context neu — Singleton-Beans bekommen neue Instanzen."

Weiterlernen: Buchkapitel

Frage 8​

Ein Service hat ein obligatorisches Repository und einen optionalen Metrics Collector, der in manchen Profilen fehlen kann.

Welcher Injection-Stil drückt optionale Abhängigkeits-Semantik am besten aus?


@Service
public class CheckoutService {
  private final OrderRepository orderRepository;
  // optionaler MetricsCollector kann fehlen
}
  • A) Required Konstruktor-Injection für beide Abhängigkeiten — Startup schlägt fehl, wenn Metrics fehlt
  • B) Feld-Injection mit @Autowired auf beiden Feldern
  • C) Konstruktor für OrderRepository plus Optional<MetricsCollector> oder @Autowired(required = false)
  • D) Statische Factory-Methode auf CheckoutService, aufgerufen aus main
Antwort & Erklärung

Richtige Antwort: C

Pflicht-Deps gehören in den required Konstruktor. Optionale Deps nutzen Optional<T>, @Nullable oder @Autowired(required = false) auf Setter/Feld. Konstruktor-Injection optionaler Deps kann Optional-Parameter in Spring Framework 4.3+ nutzen.

Warum die anderen Optionen falsch sind:

  • A) Required Konstruktor-Injection macht den optionalen Bean obligatorisch und scheitert beim Startup, wenn er fehlt.
  • B) Feld-Injection funktioniert, ist aber weniger explizit über required vs optional und schwerer zu testen.
  • D) Manuelle Factory umgeht das IoC-Container-Wiring-Modell.

Merksatz: „Pflicht-Deps im Konstruktor; optionale Deps via Optional, required=false oder @Nullable."

Weiterlernen: Buchkapitel

Frage 9​

Packages sind über Module verteilt: @SpringBootApplication sitzt in com.acme.app, Komponenten in com.acme.billing und com.acme.shipping.

Beans in com.acme.billing werden beim Startup nicht entdeckt. Was ist die wahrscheinlichste Lösung?

  • A) @EnableAutoConfiguration auf jeder Subpackage-Klasse hinzufügen
  • B) @ComponentScan(basePackages = "com.acme") hinzufügen oder einen Scan-Root teilen/verschieben, der beide Subpackages einschließt
  • C) Packages umbenennen, sodass jede Klasse direkt unter com.acme.app liegt
  • D) @Service in jedem Subpackage durch @Bean ersetzen
Antwort & Erklärung

Richtige Antwort: B

Default-Scanning startet im Package von @SpringBootApplication und dessen Nachfahren. Geschwister-Packages (com.acme.billing) liegen außerhalb dieses Baums, außer du erweiterst @ComponentScan oder strukturierst Packages um.

Warum die anderen Optionen falsch sind:

  • A) @EnableAutoConfiguration aktiviert Boot Auto-Config; es ersetzt nicht Component-Scan-Basis-Packages.
  • C) Umstrukturierung kann funktionieren, aber Scan erweitern ist die direkte Lösung; alles umbenennen ist unnötig.
  • D) @Bean pro Klasse ist verbose und löst Scan-Sichtbarkeit nicht von selbst.

Merksatz: „Component Scan sieht nur das annotierte Package und Subpackages — Geschwister brauchen explizite basePackages."

Weiterlernen: Buchkapitel

Frage 10​

Ein Entwickler fragt, ob Spring die Notwendigkeit von Factories, Singletons und Dependency Graphs im Anwendungsdesign eliminiert.

Welches Problem löst Springs IoC-Container primär?

  • A) Er kompiliert Java-Quellen schneller als javac
  • B) Er ersetzt JDBC automatisch durch Object Mapping
  • C) Er entfernt die Notwendigkeit von Interfaces im Service-Design
  • D) Er zentralisiert Objekterzeugung und Verdrahtung, sodass Klassen auf Geschäftslogik statt Collaborator-Suche fokussieren
Antwort & Erklärung

Richtige Antwort: D

Spring adressiert enge Kopplung und verstreute new/Lookup-Code durch Verwaltung des Objektgraphen. Klassen deklarieren Abhängigkeiten; der Container assembliert sie. Es eliminiert nicht Design-Bedürfnisse wie Interfaces oder Persistence-Technologiewahl.

Warum die anderen Optionen falsch sind:

  • A) Spring ist ein Runtime-Framework, kein Compiler.
  • B) Datenzugriff wird von Spring Data/JPA-Modulen adressiert, nicht von IoC selbst.
  • C) Interfaces bleiben ein Design-Werkzeug; Spring funktioniert mit und ohne sie.

Merksatz: „Spring löst Verdrahtung und Lifecycle — nicht Kompilierung, ORM oder gutes Design eliminieren."

Weiterlernen: Buchkapitel

Frage 11​

Die Property app.retry.max=3 soll an ein Konfigurationsklassenfeld mit sicherem Default binden, wenn die Property fehlt.

Welche Deklaration bindet die Property korrekt mit Default-Wert 3?


@Component
public class RetrySettings {
  // welche Felddeklaration ist korrekt?
}
  • A) @Value("${app.retry.max:3}") private int maxRetries;
  • B) @Value("app.retry.max=3") private int maxRetries;
  • C) @ConfigurationProperties("app.retry") mit nur @DefaultValue am Feld
  • D) @PropertySource("3") private int maxRetries;
Antwort & Erklärung

Richtige Antwort: A

Spring-@Value-Placeholder-Syntax unterstützt Defaults nach einem Doppelpunkt: $\{property.name:defaultValue\}. @ConfigurationProperties bindet Präfixe aus der Umgebung, nutzt aber andere Default-Mechanismen (Feldinit oder @DefaultValue in Boot 2.4+).

Warum die anderen Optionen falsch sind:

  • B) Das ist keine gültige Placeholder-Syntax; es würde als Literal behandelt oder fehlschlagen.
  • C) @ConfigurationProperties braucht Präfix und Property-Name-Mapping; @DefaultValue allein ohne korrektes Binding ist im gezeigten Snippet unvollständig.
  • D) @PropertySource benennt einen Properties-Datei-Ort, keinen Inline-Default-Wert.

Merksatz: „$\{key:default\} in @Value liefert einen Fallback, wenn die Property fehlt."

Weiterlernen: Buchkapitel

Frage 12​

Datenbank-Einstellungen sollen aus app.datasource.*-Keys in ein typsicheres Objekt binden, das in @Configuration genutzt wird.

Welcher Ansatz ist am wartbarsten für mehrere zusammengehörige Properties?


app.datasource.url=jdbc:postgresql://db:5432/orders
app.datasource.username=app
app.datasource.pool-size=10
  • A) Drei separate @Value-Injections in DataSourceConfig
  • B) Eine @Bean-Methode, die System.getenv() manuell liest
  • C) Eine @ConfigurationProperties(prefix = "app.datasource")-Klasse mit @EnableConfigurationProperties
  • D) Werte in @Bean-Methoden hardcoden und nur in Produktion überschreiben
Antwort & Erklärung

Richtige Antwort: C

@ConfigurationProperties gruppiert zusammengehörige Einstellungen mit Validierung und relaxed binding. Es skaliert besser als viele @Value-Felder und hält Konfiguration strukturiert.

Warum die anderen Optionen falsch sind:

  • A) Mehrere @Value-Felder funktionieren, werden aber brüchig, wenn die Property-Anzahl wächst.
  • B) Manuelle Env-Reads umgehen Springs Binding, Validierung und Test-Property-Unterstützung.
  • D) Hardcoding verfehlt externalisierte Konfigurationsziele.

Merksatz: „Gruppierte externe Config → @ConfigurationProperties plus Enablement; verstreute Skalare → @Value."

Weiterlernen: Buchkapitel

Frage 13​

Beans mit @Profile("postgres") sollen nur laden, wenn das Profil postgres in einer Spring-Boot-App aktiv ist.

Welche Aktivierungsmethode ist gültig?


@Profile("postgres")
@Repository
public class PostgresOrderRepository implements OrderRepository { }
  • A) Nur die Main-Klasse mit @Profile("postgres") annotieren
  • B) spring.profiles.active=postgres in Konfiguration setzen oder --spring.profiles.active=postgres übergeben
  • C) Die Bean-Klasse in PostgresOrderRepository umbenennen
  • D) @Primary auf den profilspezifischen Bean setzen
Antwort & Erklärung

Richtige Antwort: B

Profile aktivieren über spring.profiles.active (Property, Env-Var, Command Line oder @ActiveProfiles in Tests). @Profile auf Beans gated Registrierung, wenn dieses Profil aktiv ist.

Warum die anderen Optionen falsch sind:

  • A) @Profile auf der Main-Klasse ist unüblich und aktiviert das Profil nicht von selbst.
  • C) Klassennamen aktivieren keine Spring-Profile.
  • D) @Primary wählt unter konkurrierenden Beans desselben Typs; es aktiviert keine Profile.

Merksatz: „Profile werden über spring.profiles.active aktiviert, nicht allein durch Namenskonventionen."

Weiterlernen: Buchkapitel

Frage 14​

Ein Singleton ShoppingCartFacade injiziert einen prototype-scoped PromotionCalculator.

Wie viele PromotionCalculator-Instanzen existieren über die Lebensdauer eines ShoppingCartFacade-Singletons?


@Service
@Scope("singleton")
public class ShoppingCartFacade {
  private final PromotionCalculator calculator; // prototype bean
}
  • A) Genau eine — Prototype-Scope kollabiert zu Singleton, wenn in einen Singleton injiziert
  • B) Null — Prototype-Beans können nicht in Singletons injiziert werden
  • C) Eine pro HTTP-Request automatisch
  • D) Eine pro Injection-Auflösung in den Singleton — standardmäßig wird beim Startup eine Instanz injiziert und wiederverwendet
Antwort & Erklärung

Richtige Antwort: D

Einen Prototype-Bean in einen Singleton zu injizieren erfasst typischerweise eine Prototype-Instanz zur Singleton-Erzeugungszeit. Für per-Use-Prototype-Verhalten nutze ObjectProvider<T>, @Lookup oder Scoped-Proxy-Muster.

Warum die anderen Optionen falsch sind:

  • A) Prototype kollabiert nicht; das Problem ist Injection-Timing, das eine Instanz erfasst.
  • B) Injection ist erlaubt; die Semantik überrascht Teams.
  • C) Per-Request-Verhalten braucht Web-Scope oder expliziten Lookup, nicht Prototype-in-Singleton allein.

Merksatz: „Prototype in Singleton = eine Instanz bei Injection erfasst, außer du nutzt ObjectProvider oder @Lookup."

Weiterlernen: Buchkapitel

Frage 15​

Ein Nicht-Web-Integrationstest versucht, einen @Scope("request")-Bean ohne Web-Context zu erzeugen.

Was ist das wahrscheinliche Ergebnis?

  • A) Context schlägt fehl, weil Request-Scope einen aktiven Web/Request-Context braucht
  • B) Der Bean wird still zu Singleton-Scope
  • C) Spring erzeugt automatisch einen neuen Request-Scope pro Testmethode
  • D) Der Bean wird stattdessen als Prototype erzeugt
Antwort & Erklärung

Richtige Antwort: A

Request- (und Session-)Scopes brauchen RequestContextListener / Spring MVC oder WebFlux Request Context. Außerhalb eines Web-Contexts schlägt Scoped-Bean-Erzeugung fehl, außer du nutzt @Scope mit Test-MockHttpServletRequest oder Custom Scope.

Warum die anderen Optionen falsch sind:

  • B) Scope downgraded nicht still; fehlender Context verursacht Fehler.
  • C) Tests liefern keinen Auto-Request-Context ohne @WebAppConfiguration oder MockMvc-Setup.
  • D) Scope wird bei Fehler nicht automatisch zu Prototype konvertiert.

Merksatz: „Request/Session-Scopes brauchen einen live Web-Request-Context — plain Tests scheitern ohne Faking."

Weiterlernen: Buchkapitel

Frage 16​

Ein Singleton UserPreferencesService muss den aktuellen Request-LocaleContext-Bean sehen.

Welche Technik injiziert den aktuellen Request-Scoped Bean korrekt in einen Singleton?


@Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS)
@Component
public class LocaleContext { }
  • A) Direkte Konstruktor-Injection von LocaleContext in den Singleton ohne Proxy
  • B) UserPreferencesService stattdessen als @Scope("request") markieren
  • C) Scoped Proxy nutzen (proxyMode = TARGET_CLASS oder INTERFACES), sodass der Singleton einen Proxy hält, der pro Request delegiert
  • D) LocaleContext manuell in statischem ThreadLocal speichern und Spring-Scopes überspringen
Antwort & Erklärung

Richtige Antwort: C

Scoped Proxies lassen kürzer lebende Beans in länger lebende injizieren. Der Proxy löst die korrekte Instanz pro Request (oder Session) zur Methodenaufrufzeit auf.

Warum die anderen Optionen falsch sind:

  • A) Direkte Injection erfasst eine Request-Instanz bei Singleton-Init — falsches Lifecycle.
  • B) Den Singleton request-scoped zu machen ist oft unerwünscht und ändert die Service-Lebensdauer.
  • D) Manuelles ThreadLocal umgeht Springs Scoped-Proxy-Maschinerie und ist fehleranfällig.

Merksatz: „Singleton braucht Request-Bean → Scoped Proxy (TARGET_CLASS oder INTERFACES)."

Weiterlernen: Buchkapitel

Frage 17​

Ein Bean soll loggen, wenn er vollständig konstruiert ist, und erneut beim Context-Shutdown.

Welches Callback-Paar ist Standard für Init und Destroy in einem Spring-verwalteten Bean?


@Component
public class CacheWarmer {
  @PostConstruct
  void warm() { }

  @PreDestroy
  void shutdown() { }
}
  • A) @PostConstruct und @PreDestroy (JSR-250) oder InitializingBean / DisposableBean
  • B) @Before und @After aus JUnit
  • C) @Transactional-Start- und Rollback-Callbacks
  • D) main() und System.exit()
Antwort & Erklärung

Richtige Antwort: A

Spring unterstützt @PostConstruct/@PreDestroy, initMethod/destroyMethod auf @Bean und InitializingBean/DisposableBean. Diese laufen an container-verwalteten Lifecycle-Punkten.

Warum die anderen Optionen falsch sind:

  • B) JUnit-Annotationen sind für Tests, nicht Bean-Lifecycle im Container.
  • C) Transaction-Callbacks betreffen Transaktionsgrenzen, nicht allgemeines Bean Init/Destroy.
  • D) Keine Container-Lifecycle-Hooks.

Merksatz: „Bean-Lifecycle-Hooks: @PostConstruct / @PreDestroy oder @Bean(initMethod, destroyMethod)."

Weiterlernen: Buchkapitel

Frage 18​

Eine @Component-Klasse (nicht @Configuration) enthält zwei @Bean-Methoden, die sich gegenseitig aufrufen.

Was gilt über Inter-@Bean-Methodenaufrufe in dieser @Component-Klasse?

  • A) Sie verhalten sich identisch zu Full-@Configuration-Modus mit CGLIB-Singleton-Enforcement
  • B) Spring Lite-@Bean-Modus proxyt Inter-Methodenaufrufe nicht — jeder Aufruf kann eine neue Instanz erzeugen
  • C) Inter-@Bean-Aufrufe sind verboten und verursachen Kompilierungsfehler
  • D) Nur @Repository-Klassen können @Bean-Methoden hosten
Antwort & Erklärung

Richtige Antwort: B

@Bean in @Component nutzt Lite Configuration (kein CGLIB-Subclass-Proxy für @Bean-Inter-Calls). Eine @Bean-Methode von einer anderen aufzurufen umgeht den Container und kann doppelte Instanzen erzeugen.

Warum die anderen Optionen falsch sind:

  • A) Volle Proxy-Semantik braucht @Configuration, nicht plain @Component.
  • C) Es ist erlaubt, aber semantisch anders als Full Configuration Mode.
  • D) Jede @Component kann @Bean-Methoden im Lite Mode deklarieren.

Merksatz: „@Bean in @Component = Lite Mode; Inter-Methodenaufrufe sind nicht container-geproxyt."

Weiterlernen: Buchkapitel

Frage 19​

Eine neue Spring-Boot-Anwendung braucht Component Scanning, Auto-Configuration und Spring-Boot-Configuration-Property-Unterstützung.

Welche Kombination meta-annotiert @SpringBootApplication?


@SpringBootApplication
public class InventoryApplication {
  public static void main(String[] args) {
    SpringApplication.run(InventoryApplication.class, args);
  }
}
  • A) @SpringBootConfiguration, @EnableAutoConfiguration und @ComponentScan (mit optionaler Scan-Anpassung)
  • B) Nur @ComponentScan und @EnableWebMvc
  • C) @Configuration, @EnableScheduling und @EnableJpaRepositories
  • D) Nur @SpringBootConfiguration und @Profile("default")
Antwort & Erklärung

Richtige Antwort: A

@SpringBootApplication kombiniert @SpringBootConfiguration (spezialisierte @Configuration), @EnableAutoConfiguration und @ComponentScan auf dem Application-Class-Package.

Warum die anderen Optionen falsch sind:

  • B) @EnableWebMvc ist nicht Teil von @SpringBootApplication; Boot auto-konfiguriert MVC.
  • C) Scheduling und JPA Repos brauchen eigene Enable-Annotationen, wenn nötig.
  • D) Es enthält Auto-Configuration und Component Scanning, nicht nur @SpringBootConfiguration.

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

Weiterlernen: Buchkapitel

Frage 20​

Eine Custom Auto-Configuration soll einen MetricsExporter nur registrieren, wenn die Klasse io.micrometer.core.MeterRegistry im Classpath ist.

Welche Condition-Annotation passt?


@AutoConfiguration
@ConditionalOnClass(MeterRegistry.class)
public class MetricsExportAutoConfiguration {
  @Bean
  MetricsExporter metricsExporter(MeterRegistry registry) { ... }
}
  • A) @ConditionalOnMissingClass("io.micrometer.core.MeterRegistry")
  • B) @Profile("metrics")
  • C) @ConditionalOnClass(MeterRegistry.class)
  • D) Nur @ConditionalOnBean(MeterRegistry.class), ohne Classpath-Check
Antwort & Erklärung

Richtige Antwort: C

@ConditionalOnClass schützt Auto-Config basierend auf Classpath-Anwesenheit (mit String-Name oder Klassenreferenz — vorsichtig bei fehlenden Klassen). @ConditionalOnBean prüft bestehende Beans, nicht Classpath allein.

Warum die anderen Optionen falsch sind:

  • A) Diese Condition aktiviert, wenn die Klasse fehlt — gegenteilige Absicht.
  • B) Profile sind orthogonal zu Classpath-Bedingungen.
  • D) @ConditionalOnBean ersetzt keinen Classpath-Guard; beide können kombiniert werden, aber die Frage fragt nach Classpath-Erkennung.

Merksatz: „Classpath vorhanden → @ConditionalOnClass; Bean bereits definiert → @ConditionalOnBean."

Weiterlernen: Buchkapitel

Frage 21​

Spring Boot 3 registriert Auto-Configuration-Klassen anders als ältere META-INF/spring.factories-Einträge.

Wo sollten Boot-3-Auto-Configuration-Klassen gelistet werden?

  • A) Nur in application.properties unter spring.auto.configure
  • B) In META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
  • C) In META-INF/services/java.sql.Driver
  • D) Nur über @ComponentScan auf dem Auto-Config-Package
Antwort & Erklärung

Richtige Antwort: B

Spring Boot 2.7+ führte AutoConfiguration.imports ein; Boot 3 nutzt es statt spring.factories für Auto-Config-Klassen-Registrierung.

Warum die anderen Optionen falsch sind:

  • A) Keine solche Standard-Property listet Auto-Config-Klassen.
  • C) JDBC-Driver-Service-Dateien sind unabhängig von Spring-Boot-Auto-Configuration-Registrierung.
  • D) Auto-Config wird von Boot über Imports-Datei und Conditions importiert, nicht nur Component Scan.

Merksatz: „Boot-3-Auto-Config-Registrierung → META-INF/spring/...AutoConfiguration.imports."

Weiterlernen: Buchkapitel

Frage 22​

Operations braucht die Default-Actuator-Health-Endpoint-URL auf einer Boot-Web-App ohne Custom Management Context Path.

Was ist die Default-URL für den Health-Endpoint, wenn er über Web exponiert wird?

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

Richtige Antwort: D

Standardmäßig liegen Actuator-Web-Endpoints unter /actuator mit angehängter Endpoint-ID: /actuator/health. Exposure hängt auch von management.endpoints.web.exposure.include ab.

Warum die anderen Optionen falsch sind:

  • A) /health ist in Apps üblich, aber nicht der Boot-Actuator-Default-Basis-Pfad.
  • B) /api/health ist anwendungsspezifisch, nicht Actuator-Default.
  • C) /status ist nicht der Default-Actuator-Health-Pfad.

Merksatz: „Default-Actuator-Basis-Pfad ist /actuator → Health ist /actuator/health."

Weiterlernen: Buchkapitel

Frage 23​

Ein sicherheitsbewusstes Team will nur health und info über HTTP in Produktion exponieren.

Welche Property-Konfiguration erreicht selektive Web-Exposure?

  • A) management.endpoints.web.exposure.include=health,info
  • B) management.server.port=0
  • C) spring.actuator.enabled=false
  • D) server.port=-1
Antwort & Erklärung

Richtige Antwort: A

management.endpoints.web.exposure.include steuert, welche Actuator-Endpoints im Web exponiert werden. Nutze exclude für Deny-Lists oder include=* mit Vorsicht.

Warum die anderen Optionen falsch sind:

  • B) Port 0 weist einen zufälligen Port zu, wählt aber nicht, welche Endpoints exponiert werden.
  • C) Actuator komplett deaktivieren ist breiter als selektive Exposure.
  • D) Ungültige/Haupt-Server-Port-Einstellung; unabhängig von Endpoint-Exposure-Auswahl.

Merksatz: „Spezifische Actuator-Endpoints exponieren → management.endpoints.web.exposure.include."

Weiterlernen: Buchkapitel

Frage 24​

Eine Bibliotheks-Auto-Config definiert einen Default-ObjectMapper-Bean, aber die Anwendung liefert bereits ihren eigenen @Bean ObjectMapper.

Mit @ConditionalOnMissingBean(ObjectMapper.class) auf dem Auto-Config-@Bean, was passiert?


@Configuration
public class JacksonAutoConfiguration {
  @Bean
  @ConditionalOnMissingBean(ObjectMapper.class)
  ObjectMapper objectMapper() { return new ObjectMapper(); }
}
  • A) Beide Beans werden registriert und @Primary entscheidet
  • B) Auto-Config überschreibt immer User-Beans
  • C) Der auto-konfigurierte ObjectMapper wird übersprungen, weil ein Bean dieses Typs bereits existiert
  • D) Context schlägt wegen doppelter Bean-Definitionen fehl
Antwort & Erklärung

Richtige Antwort: C

@ConditionalOnMissingBean verhindert, dass Auto-Config einen Default registriert, wenn der User (oder andere Config) diesen Bean-Typ bereits definiert hat.

Warum die anderen Optionen falsch sind:

  • A) Die Condition vermeidet doppelte Registrierung statt zwei konkurrierende Beans zu erzeugen.
  • B) User-Beans haben Vorrang; Auto-Config tritt zurück.
  • D) Zurücktreten verhindert den Duplicate-Definition-Fehler.

Merksatz: „@ConditionalOnMissingBean = Auto-Config weicht, wenn du den Bean bereits definiert hast."

Weiterlernen: Buchkapitel

Frage 25​

Ein Projekt fügt spring-boot-starter-data-jpa hinzu, ohne einzelne Hibernate- oder JDBC-Artefaktversionen anzugeben.

Wie bestimmt Spring Boot kompatible Dependency-Versionen?

  • A) Maven-Central-Latest-Version jedes Artefakts zur Build-Zeit
  • B) Dependency-Versionen werden vom Spring-Boot-BOM verwaltet, importiert über Starter Parent oder dependencyManagement
  • C) Versionen müssen in jeder pom.xml-Dependency explizit deklariert werden
  • D) Nur Gradle-Projekte bekommen Version Management; Maven nicht
Antwort & Erklärung

Richtige Antwort: B

Spring-Boot-Starter importieren das Boot-BOM, das getestete Versionen für transitive Dependencies festlegt. Du lässt Versionsnummern für verwaltete Koordinaten weg.

Warum die anderen Optionen falsch sind:

  • A) Boot löst nicht auf beliebiges Latest auf; es nutzt kuratierte BOM-Versionen.
  • C) Explizite Versionen sind optional für BOM-verwaltete Dependencies.
  • D) Sowohl Maven als auch Gradle unterstützen Boot Dependency Management.

Merksatz: „Boot Starter + BOM = kuratierte kompatible Versionen ohne manuelle Version Pins."

Weiterlernen: Buchkapitel

Frage 26​

Zwei Startup-Hooks existieren: ApplicationRunner und CommandLineRunner. Beide sind @Bean-Methoden mit @Order-Annotationen.

Wann laufen diese Runner relativ dazu, dass die Anwendung bereit ist, Traffic zu bedienen?

  • A) Bevor der ApplicationContext refreshed wird
  • B) Nur nach manuellem Aufruf aus main nach Rückkehr von SpringApplication.run
  • C) Während der Bean-Registrierung, bevor Beans instanziiert werden
  • D) Nach abgeschlossenem Context-Refresh/Start als Teil des Application-Startups, bevor SpringApplication.run zurückkehrt
Antwort & Erklärung

Richtige Antwort: D

Runner laufen, nachdem der Context steht und Beans initialisiert sind — als finale Startup-Phase. @Order steuert die relative Reihenfolge unter Runnern.

Warum die anderen Optionen falsch sind:

  • A) Context muss zuerst refreshed sein; Runner laufen nach bereiter Startup-Infrastruktur.
  • B) Sie laufen automatisch beim Startup, nicht nur bei manuellem Aufruf nach run-Rückkehr.
  • C) Sie laufen nach Bean-Erzeugung, nicht während Registrierung.

Merksatz: „Runner feuern nach abgeschlossenem Context-Startup, geordnet durch @Order, bevor run() zurückkehrt."

Weiterlernen: Buchkapitel

Frage 27​

Ein großer Monolith hat langsamen Startup, weil Hunderte ungenutzter Beans eager initialisiert werden.

Welche Einstellung aktiviert Lazy Initialization von Beans standardmäßig in Spring Boot?


# application.properties
spring.main.lazy-initialization=true
  • A) spring.main.lazy-initialization=true
  • B) spring.jpa.open-in-view=false
  • C) management.endpoints.enabled-by-default=false
  • D) server.tomcat.lazy=true
Antwort & Erklärung

Richtige Antwort: A

spring.main.lazy-initialization=true sagt Boot, Beans lazy zu erzeugen, außer sie sind @Lazy(false) markiert oder eager erforderlich. Es kann Fehler verzögern und Startup-Arbeit reduzieren.

Warum die anderen Optionen falsch sind:

  • B) OSIV betrifft Persistence-Session-Länge in Web-Apps, nicht globale Bean-Lazy-Init.
  • C) Steuert Actuator-Endpoint-Defaults, nicht Bean-Initialisierungs-Timing.
  • D) Keine Standard-Spring-Boot-Property für Bean-Laziness.

Merksatz: „Globale lazy Beans in Boot → spring.main.lazy-initialization=true."

Weiterlernen: Buchkapitel

Frage 28​

Eine Feature-Flag-Property features.export.enabled=true muss eine Auto-Configuration-Klasse gaten.

Welche Condition passt am besten?

  • A) Nur @ConditionalOnClass
  • B) Nur @Profile("export") ohne Property
  • C) @ConditionalOnProperty(name = "features.export.enabled", havingValue = "true")
  • D) @Transactional
Antwort & Erklärung

Richtige Antwort: C

@ConditionalOnProperty matcht Environment-Property-Werte (mit havingValue, matchIfMissing). Ideal für Feature Flags neben anderen Conditions.

Warum die anderen Optionen falsch sind:

  • A) Classpath-Checks lesen keine booleschen Feature-Properties.
  • B) Profile können Flags spiegeln, aber die Frage zielt auf einen spezifischen Property-Wert.
  • D) @Transactional ist unabhängig von bedingter Auto-Configuration.

Merksatz: „Feature Flags in Auto-Config → @ConditionalOnProperty mit havingValue."

Weiterlernen: Buchkapitel

Frage 29​

Ein HTTP GET /orders/42 soll eine Controller-Methode erreichen und JSON zurückgeben.

Was ist die primäre Rolle von DispatcherServlet in diesem Flow?


Client GET /orders/42
  -> DispatcherServlet
  -> HandlerMapping / Controller
  -> HttpMessageConverter (JSON)
  • A) Er kompiliert Controller-Bytecode zur Laufzeit
  • B) Er frontet die Web-Schicht, dispatcht Requests an Handler und rendert/konvertiert Responses
  • C) Er ersetzt Controller, indem er URLs direkt auf Repositories mappt
  • D) Er verwaltet JPA-Transaktionen für @RestController-Methoden automatisch
Antwort & Erklärung

Richtige Antwort: B

DispatcherServlet ist Spring MVCs Front Controller. Er löst Handler Mappings auf, ruft Controller auf und koordiniert View Resolution oder Message Conversion.

Warum die anderen Optionen falsch sind:

  • A) Er ist ein Servlet-Dispatcher, kein Compiler.
  • C) Controller (oder Handler-Methoden) bleiben die gemappten Endpoints.
  • D) Transaktionen kommen von @Transactional AOP, nicht direkt von DispatcherServlet.

Merksatz: „DispatcherServlet = Front Controller, der Requests an Handler und Response-Verarbeitung routet."

Weiterlernen: Buchkapitel

Frage 30​

Ein REST-Endpoint muss page und size Query-Parameter und das \{accountId\}-Pfadsegment lesen.

Welche Annotation-Kombination ist korrekt?


@GetMapping("/accounts/{accountId}/transactions")
public List<Tx> list(
    @PathVariable String accountId,
    @RequestParam int page,
    @RequestParam int size) { ... }
  • A) @RequestParam für accountId und @PathVariable für page
  • B) Beide sollten @RequestBody nutzen
  • C) Beide sollten nur @ModelAttribute nutzen
  • D) @PathVariable für Pfadsegmente und @RequestParam für Query-Parameter — wie gezeigt
Antwort & Erklärung

Richtige Antwort: D

Path-Template-Variablen nutzen @PathVariable. Query-String-Parameter nutzen @RequestParam. Der gezeigte Code folgt Spring-MVC-Konventionen.

Warum die anderen Optionen falsch sind:

  • A) Vertauscht die korrekte Zuordnung für Pfad vs Query.
  • B) @RequestBody liest den HTTP-Body, nicht Pfad- oder Query-Teile bei GET.
  • C) @ModelAttribute bindet Form/Query an Objekte; nicht das idiomatische Paar für explizite Pfad- plus Query-Parameter.

Merksatz: „Path-Template → @PathVariable; Query-String → @RequestParam."

Weiterlernen: Buchkapitel

Frage 31​

Ein Controller wirft OrderNotFoundException für fehlende Ressourcen. API-Clients sollen HTTP 404 mit JSON-Error-Body erhalten.

Was ist der sauberste MVC-Ansatz, um die Exception konsistent über Controller auf 404 zu mappen?

  • A) Eine @ControllerAdvice-Klasse mit @ExceptionHandler(OrderNotFoundException.class), die ResponseEntity oder Problem Details zurückgibt
  • B) Nur throws OrderNotFoundException in jeder Controller-Signatur hinzufügen
  • C) Die Exception im DispatcherServlet-Source-Code fangen
  • D) Nur @ResponseStatus auf der Controller-Klasse nutzen
Antwort & Erklärung

Richtige Antwort: A

Globales @ControllerAdvice + @ExceptionHandler zentralisiert Exception-zu-HTTP-Mapping. @ResponseStatus auf Exception-Klassen ist auch gültig; Advice skaliert besser für Response Bodies.

Warum die anderen Optionen falsch sind:

  • B) throws deklarieren setzt weder Statuscodes noch Bodies für Clients.
  • C) Du solltest Framework-Servlet-Code nicht modifizieren.
  • D) Klassen-Level-@ResponseStatus auf einem Controller behandelt nicht geworfene Exceptions aus Handler-Methoden.

Merksatz: „Zentrales HTTP-Error-Mapping → @ControllerAdvice + @ExceptionHandler."

Weiterlernen: Buchkapitel

Frage 32​

Clients können für denselben Endpoint JSON oder XML anfordern — basierend auf dem Accept-Header.

Welcher Mechanismus wählt das Response-Format?


@GetMapping(value = "/reports", produces = { MediaType.APPLICATION_JSON_VALUE, MediaType.APPLICATION_XML_VALUE })
public Report getReport() { ... }
  • A) Nur @RequestParam("format") wird nativ unterstützt
  • B) Zufällige Auswahl unter registrierten HttpMessageConverter-Instanzen
  • C) Content Negotiation über Accept-Header, produces und registrierte Message Converter
  • D) Der Datenbank-Spaltentyp entscheidet JSON vs XML
Antwort & Erklärung

Richtige Antwort: C

Spring-MVC-Content-Negotiation nutzt Accept, produces/consumes-Attribute und Converter (Jackson, JAXB usw.) zur Repräsentationswahl.

Warum die anderen Optionen falsch sind:

  • A) Format-Query-Parameter können konfiguriert werden, aber native Negotiation zentriert auf Accept und Converter.
  • B) Auswahl ist deterministisch basierend auf Negotiation-Regeln.
  • D) Persistence-Typen treiben nicht das HTTP-Repräsentationsformat.

Merksatz: „Response-Format → Content Negotiation (Accept, produces, Message Converter)."

Weiterlernen: Buchkapitel

Frage 33​

Ein POST-Endpoint akzeptiert einen JSON-Body, der vor der Service-Schicht validiert werden muss.

Welche Controller-Signatur triggert Bean Validation am Request Body?


@PostMapping("/customers")
public ResponseEntity<Customer> create(@Valid @RequestBody CustomerRequest request) {
  return ResponseEntity.ok(service.create(request));
}
  • A) @Valid entfernen — Validierung läuft automatisch auf allen Bodies
  • B) @Valid @RequestBody am Parameter plus Validierungs-Annotationen auf CustomerRequest-Feldern
  • C) Nur @ModelAttribute triggert JSON-Validierung
  • D) Nur die Service-Methode mit @Validated annotieren, nicht den Controller-Parameter
Antwort & Erklärung

Richtige Antwort: B

@Valid (oder @Validated) auf @RequestBody triggert JSR-380-Validierung am Objektgraphen. Ungültige Requests erzeugen typischerweise MethodArgumentNotValidException, behandelt von MVC Advice.

Warum die anderen Optionen falsch sind:

  • A) Validierung läuft auf Request Bodies nicht ohne @Valid/@Validated.
  • C) @ModelAttribute ist für Form-Data-Binding, nicht typische JSON-@RequestBody-Validierung.
  • D) Service-Level-@Validated validiert dort Methodenparameter, nicht den MVC-Layer-Request-Body, außer auch am Einstieg annotiert.

Merksatz: „JSON-Bodies am Controller validieren mit @Valid @RequestBody auf DTOs mit Constraints."

Weiterlernen: Buchkapitel

Frage 34​

Mehrere @ControllerAdvice-Beans existieren in der Anwendung.

Wie wendet Spring MVC sie auf Controller-Exceptions und Model Attributes an?

  • A) Nur Advice im selben Package wie der Controller gilt
  • B) Advice-Beans werden nie mit @RestController genutzt
  • C) Zufälliges Advice wird pro Request gewählt
  • D) Anwendbare Advice-Beans sind geordnet (z. B. @Order) und werden gemäß Scope-Annotationen wie @ControllerAdvice(assignableTypes = OrderController.class) konsultiert
Antwort & Erklärung

Richtige Antwort: D

@ControllerAdvice kann global oder per Annotation/Packages/Assignable Types gescoped sein. @Order/@Priority beeinflusst Vorrang, wenn mehrere Advices gelten.

Warum die anderen Optionen falsch sind:

  • A) Advice ist nicht auf dasselbe Package beschränkt, außer so gescoped.
  • B) @RestController ist eine @Controller-Spezialisierung; Advice gilt.
  • C) Auswahl folgt Scope- und Ordering-Regeln, nicht Zufall.

Merksatz: „@ControllerAdvice-Scope + @Order bestimmen, welches globale MVC-Advice einen Fall behandelt."

Weiterlernen: Buchkapitel

Frage 35​

Ein Endpoint soll nur PUT-Requests auf /inventory/\{sku\} akzeptieren und POST auf denselben Pfad ablehnen.

Welches Mapping ist korrekt?

  • A) @PutMapping("/inventory/{sku}") auf der Handler-Methode
  • B) @GetMapping("/inventory/{sku}") mit manuellem Verb-Check
  • C) @RequestMapping ohne method-Attribut für alle Verben
  • D) Nur @PatchMapping für jedes Update-Szenario
Antwort & Erklärung

Richtige Antwort: A

@PutMapping ist ein zusammengesetztes @RequestMapping(method = PUT), das HTTP-Methode und Pfad einschränkt.

Warum die anderen Optionen falsch sind:

  • B) GET-Mapping lehnt PUT auf Mapping-Ebene ab, außer für mehrere Methoden konfiguriert.
  • C) Unqualifiziertes @RequestMapping kann alle Methoden akzeptieren, wenn nicht eingeschränkt.
  • D) PATCH ist für partielle Updates; die Frage fragt spezifisch nach PUT-only.

Merksatz: „HTTP-Verb einschränken mit zusammengesetzten Mappings wie @PutMapping, @PostMapping usw."

Weiterlernen: Buchkapitel

Frage 36​

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

Welches Controller-Attribut lehnt Nicht-JSON-Request-Bodies für diesen Handler ab?

  • A) consumes = "application/json" auf der Mapping-Annotation
  • B) Nur produces = "application/json"
  • C) response = JSON
  • D) @Transactional(readOnly = true)
Antwort & Erklärung

Richtige Antwort: A

consumes spezifiziert akzeptierte Request-Content-Types. produces spezifiziert Response-Types. Mismatch ergibt 415 Unsupported Media Type.

Warum die anderen Optionen falsch sind:

  • B) produces regelt Response, nicht Request-Body-Content-Type.
  • C) Kein Spring-MVC-Mapping-Attribut.
  • D) Transaktionen filtern keine Content Types.

Merksatz: „Request-Body-Typ-Gate → consumes; Response-Typ → produces."

Weiterlernen: Buchkapitel

Frage 37​

Eine Service-Methode ist mit @Transactional annotiert und ruft ein Repository save auf, das eine checked IOException wirft.

Was ist das Default-Rollback-Verhalten für diese checked Exception?


@Transactional
public void archive(Order order) throws IOException {
  repository.save(order);
  storage.write(order.getId()); // kann IOException werfen
}
  • A) Transaktion rollt bei jeder Exception inklusive checked Exceptions standardmäßig zurück
  • B) Transaktion committet, außer die Exception ist unchecked (RuntimeException/Error) — checked Exceptions rollen standardmäßig nicht zurück
  • C) Transaktionen committen immer unabhängig von Exceptions
  • D) Nur @Rollback(false) am Repository steuert Commit
Antwort & Erklärung

Richtige Antwort: B

Default-Rollback gilt für RuntimeException und Error. Checked Exceptions committen standardmäßig, außer konfiguriert mit rollbackFor / noRollbackFor.

Warum die anderen Optionen falsch sind:

  • A) Checked Exceptions triggern standardmäßig kein Rollback.
  • C) Unchecked Exceptions rollen standardmäßig zurück.
  • D) Rollback-Regeln kommen aus @Transactional-Metadaten, nicht allein aus Repository-Level-@Rollback(false) in typischen Service-Transaktionen.

Merksatz: „Default-@Transactional rollt bei unchecked Exceptions und Error zurück, nicht bei checked Exceptions."

Weiterlernen: Buchkapitel

Frage 38​

Eine read-heavy Report-Methode fragt nur Daten ab und soll unnötige Dirty Checks und Flush-Operationen vermeiden.

Welches @Transactional-Attribut hilft, read-only-Arbeit zu optimieren?

  • A) propagation = REQUIRES_NEW immer
  • B) isolation = SERIALIZABLE immer
  • C) timeout = 0
  • D) readOnly = true
Antwort & Erklärung

Richtige Antwort: D

readOnly = true signalisiert dem Persistence Provider/JDBC-Layer, dass keine Modifikationen stattfinden — das ermöglicht Optimierungen und mit manchen Setups Routing zu Read Replicas.

Warum die anderen Optionen falsch sind:

  • A) REQUIRES_NEW startet eine neue Transaktion; kein Read-Optimierungs-Hinweis.
  • B) SERIALIZABLE ist die strengste Isolation, keine Read-Only-Optimierung.
  • C) timeout = 0-Semantik hängt vom Provider ab; nicht der Standard-Read-Only-Hinweis.

Merksatz: „Read-only transaktionale Queries → readOnly = true."

Weiterlernen: Buchkapitel

Frage 39​

Ein Controller gibt eine Order-Entity mit lazy OrderLine-Children zurück. Die Transaktion endete in der Service-Schicht vor JSON-Serialisierung.

Welcher Fehler ist beim Response-Rendering am wahrscheinlichsten?

  • A) LazyInitializationException, wenn Jackson auf nicht initialisierte lazy Collections zugreift
  • B) CSRF-Token-Mismatch
  • C) Doppelte Bean-Definition für ObjectMapper
  • D) Actuator Health down
Antwort & Erklärung

Richtige Antwort: A

Zugriff auf lazy Associations außerhalb eines offenen Persistence Contexts/Sessions verursacht LazyInitializationException. Fix mit Fetch Join, DTOs, @Transactional an der Read-Grenze oder open-in-view (mit Trade-offs).

Warum die anderen Optionen falsch sind:

  • B) CSRF ist unabhängig von JPA Lazy Loading.
  • C) Jackson/ObjectMapper-Bean-Probleme sind getrennt von Lazy Loading.
  • D) Actuator Health ist unabhängig von Entity-Graph-Serialisierung.

Merksatz: „Lazy Collections außerhalb Transaktion/Session → LazyInitializationException."

Weiterlernen: Buchkapitel

Frage 40​

Ein Service ruft repository.save(entity) auf und führt dann im selben Transaction ein Bulk-JPQL-Update aus, bevor die Methode endet.

Wann werden SQL-Änderungen von save wahrscheinlich zur Datenbank geflusht relativ zum Bulk-Update?

  • A) Nie — JPA schreibt nur beim Transaction Commit
  • B) Nur nach Application-Restart
  • C) Vor oder bis zum Bulk-Update, wenn Flush Mode/Synchronisation ausstehende Änderungen sichtbar machen muss — oft bei Query-Ausführung oder Transaction Commit je nach Flush Mode
  • D) Hibernate flusht nie bei JPQL-Nutzung
Antwort & Erklärung

Richtige Antwort: C

Persistence Context trackt Änderungen; Flush kann vor Queries (Auto Flush) oder beim Commit stattfinden je nach FlushModeType. Ausstehende save-Änderungen können geflusht werden, damit Queries konsistenten State sehen.

Warum die anderen Optionen falsch sind:

  • A) Flush kann vor Commit passieren, besonders vor Queries mit AUTO Flush.
  • B) Persistence ist Runtime, nicht restart-abhängig.
  • D) JPQL kann Flush triggern, wenn Auto-Flush aktiviert ist.

Merksatz: „JPA Flush synchronisiert Persistence Context mit DB vor Commit und oft vor Queries."

Weiterlernen: Buchkapitel

Frage 41​

Ein Repository braucht eine Query, die DTO-Projektionen zurückgibt, ohne volle Entities zu laden.

Welcher Spring-Data-JPA-Ansatz unterstützt Custom Read Models effizient?


interface OrderSummaryRepository extends JpaRepository<Order, Long> {
  @Query("select new com.acme.OrderSummary(o.id, o.total) from Order o where o.status = :status")
  List<OrderSummary> findSummaries(@Param("status") String status);
}
  • A) Immer alle Order-Entities laden und manuell in einer Schleife mappen
  • B) JPQL Constructor Expression in @Query, die einen DTO/Projection-Typ zurückgibt
  • C) Nur natives SQL ohne @Query ist für DTOs erlaubt
  • D) Vor jeder Query entityManager.clear() aufrufen
Antwort & Erklärung

Richtige Antwort: B

JPQL Constructor Expressions (z. B. select new com.acme.OrderSummary(o.id, o.total)) holen nur benötigte Spalten in DTOs. Interface-basierte Projections und native Queries sind Alternativen.

Warum die anderen Optionen falsch sind:

  • A) Entity-Loading ist schwerer als Constructor/Projection Queries.
  • C) JPQL @Query unterstützt DTO Constructor Projections vollständig.
  • D) clear() detacht Entities; unabhängig von DTO-Query-Deklaration.

Merksatz: „DTO-Reads in Spring Data → JPQL Constructor Expressions oder Interface/Native Projections."

Weiterlernen: Buchkapitel

Frage 42​

Das Löschen einer Parent-Entity soll ihre Child-Zeilen automatisch aus der Datenbank entfernen.

Welches JPA-Mapping-Attribut an der Beziehung etabliert dieses Verhalten?

  • A) Nur fetch = LAZY
  • B) @Transactional auf der Child-Entity
  • C) @Version auf dem Parent
  • D) cascade = CascadeType.REMOVE (oder ALL inklusive remove) an der Parent-to-Children-Association
Antwort & Erklärung

Richtige Antwort: D

CascadeType.REMOVE propagiert Remove-Operationen auf assoziierte Entities. Orphan Removal (orphanRemoval = true) behandelt dissoziierte Children je nach Mapping.

Warum die anderen Optionen falsch sind:

  • A) Fetch Type steuert Loading, nicht Delete-Propagation.
  • B) @Transactional auf Entity-Klassen ist kein Standard-JPA-Delete-Cascading.
  • C) @Version ermöglicht Optimistic Locking, kein Cascaded Delete.

Merksatz: „Children cascade-delete → cascade = REMOVE oder orphanRemoval = true an der Association."

Weiterlernen: Buchkapitel

Frage 43​

Methode A (transaktional) ruft Methode B auf, die der bestehenden Transaktion beitreten oder eine starten muss, wenn keine existiert.

Welche Propagation-Einstellung auf Methode B matcht diese Anforderung?

  • A) Propagation.REQUIRED
  • B) Propagation.REQUIRES_NEW immer
  • C) Propagation.NOT_SUPPORTED
  • D) Propagation.NEVER
Antwort & Erklärung

Richtige Antwort: A

REQUIRED joint die aktuelle Transaktion, wenn vorhanden; sonst erzeugt es eine neue. Das ist der Default.

Warum die anderen Optionen falsch sind:

  • B) REQUIRES_NEW suspendiert aktuelle und erzeugt immer eine neue Transaktion.
  • C) NOT_SUPPORTED suspendiert Transaktionen.
  • D) NEVER schlägt fehl, wenn bereits eine Transaktion existiert.

Merksatz: „Default Join-or-Create-Verhalten → Propagation.REQUIRED."

Weiterlernen: Buchkapitel

Frage 44​

Orders auflisten führt 1 Query für Orders und N zusätzliche Queries pro Order-Customer aus.

Was ist der zielgerichtetste JPA-Fix für dieses N+1-Select-Problem im Read-Pfad?

  • A) Logging deaktivieren
  • B) Nur Heap Size erhöhen
  • C) Fetch Join oder @EntityGraph nutzen, um Customers mit Orders in einer Query zu laden
  • D) Alle Entities auf @Embeddable umstellen
Antwort & Erklärung

Richtige Antwort: C

N+1 entsteht durch Lazy Loading pro Zeile. join fetch, @EntityGraph oder Batch Fetching (@BatchSize) reduzieren Roundtrips.

Warum die anderen Optionen falsch sind:

  • A) Logging-Änderungen ändern Query-Muster nicht.
  • B) Speicher behebt nicht übermäßige Query-Anzahl.
  • D) Embeddable-Mapping-Redesign ist unabhängig von Fetch-Strategie für Associations.

Merksatz: „N+1-Fix → Fetch Join, @EntityGraph oder Batch Size — assoziierte Daten effizient laden."

Weiterlernen: Buchkapitel

Frage 45​

Eine Spring-Boot-App konfiguriert Security mit einem Custom-SecurityFilterChain-Bean.

Wo passt SecurityFilterChain in die Request-Processing-Pipeline?


HTTP request
  -> SecurityFilterChain (JwtAuthFilter, AuthorizationFilter, ...)
  -> DispatcherServlet
  -> Controller
  • A) Er ersetzt DispatcherServlet vollständig
  • B) Er läuft nur, nachdem Controller-Methoden zurückkehren
  • C) Er ist eine Datenbank-Connection-Pool-Konfiguration
  • D) Er ist eine Kette von Servlet-Filtern (inklusive Security-Filter), die vor Spring MVC auf den Request angewendet werden
Antwort & Erklärung

Richtige Antwort: D

Spring Security ist filter-basiert. SecurityFilterChain definiert geordnete Security-Filter (Auth, Authorization usw.) in der Servlet-Chain vor Dispatcher-Servlet-Handling.

Warum die anderen Optionen falsch sind:

  • A) MVC nutzt weiterhin DispatcherServlet; Security-Filter laufen früher in der Servlet-Chain.
  • B) Filter laufen bei eingehenden Requests vor Handlern und auf dem Rückweg.
  • C) Unabhängig von JDBC-Pooling.

Merksatz: „Spring Security = Servlet-Filter-Chain vor DispatcherServlet."

Weiterlernen: Buchkapitel

Frage 46​

User-Passwörter müssen mit einem starken adaptiven Algorithmus gehasht werden, den Spring Security empfiehlt.

Welcher Encoder ist die typische Default-Wahl in modernen Spring-Security-Apps?

  • A) Base64-Encoding ohne Salt
  • B) BCryptPasswordEncoder (oder delegating factory mit bcrypt und Upgrades)
  • C) MD5 ohne Salt
  • D) Reversible AES-Verschlüsselung von Klartext-Passwörtern
Antwort & Erklärung

Richtige Antwort: B

Spring Security empfiehlt starkes Passwort-Hashing wie BCrypt (über PasswordEncoder-Beans). Passwörter sollten One-Way gehasht werden, nicht reversibel verschlüsselt.

Warum die anderen Optionen falsch sind:

  • A) Base64 ist Encoding, kein sicheres Passwort-Hashing.
  • C) MD5 ist ungeeignet für Passwort-Speicherung.
  • D) Passwörter sollten für Verifikation gehasht werden, nicht reversibel für Speicherung verschlüsselt.

Merksatz: „Passwörter mit starkem PasswordEncoder speichern — BCrypt via delegating encoder in Boot."

Weiterlernen: Buchkapitel

Frage 47​

Method Security soll Zugriff nur erlauben, wenn der authentifizierte User die Rolle ADMIN hat — mit SpEL.

Welche Annotation drückt diese Regel auf einer Service-Methode aus?


@Service
public class AdminService {
  public void purgeCache() { }
}
  • A) @PreAuthorize("hasRole('ADMIN')")
  • B) @PermitAll auf der Methode
  • C) @CrossOrigin("ADMIN")
  • D) @Profile("ADMIN")
Antwort & Erklärung

Richtige Antwort: A

@PreAuthorize wendet SpEL-Authorization vor Methodenausführung an. hasRole prefixt automatisch ROLE_ für Rollennamen.

Warum die anderen Optionen falsch sind:

  • B) @PermitAll erlaubt uneingeschränkten Zugriff.
  • C) @CrossOrigin konfiguriert CORS, nicht Authorization.
  • D) @Profile aktiviert Beans nach Umgebungsprofil, nicht User-Rollen.

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

Weiterlernen: Buchkapitel

Frage 48​

Eine stateless REST-API nutzt JWT-Bearer-Tokens und keine Browser-Cookie-Session.

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

  • A) CSRF muss für alle REST-Endpoints immer voll aktiviert bleiben
  • B) Datenbank-Connection-Pooling deaktivieren
  • C) CSRF für stateless Token-APIs deaktivieren, weil Browser Bearer-Tokens nicht cross-site automatisch senden
  • D) Form Login nur mit Session-Cookies aktivieren
Antwort & Erklärung

Richtige Antwort: C

CSRF schützt Cookie-basierte Session-Auth vor Cross-Site-Requests. Stateless Bearer-Token-APIs deaktivieren CSRF oft, verlangen aber weiterhin Authentication auf geschützten Ressourcen.

Warum die anderen Optionen falsch sind:

  • A) Cookielose Bearer-APIs deaktivieren typischerweise CSRF; Cookie-basierte Apps behalten es aktiviert.
  • B) Connection Pooling ist unabhängig von CSRF.
  • D) Form Login mit Sessions ist ein anderes Auth-Modell als stateless JWT-APIs.

Merksatz: „Stateless Bearer-APIs deaktivieren oft CSRF; Cookie-Session-Apps behalten CSRF-Schutz."

Weiterlernen: Buchkapitel

Frage 49​

Eine Browser-SPA auf https://app.example.com ruft eine API auf https://api.example.com auf.

Welche Spring-Komponente adressiert Cross-Origin-Browser-Beschränkungen für erlaubte Origins und Methoden?

  • A) Nur CSRF-Token-Repository
  • B) CORS-Konfiguration (CorsConfigurationSource / http.cors)
  • C) BCrypt-Strength-Einstellung
  • D) @Transactional
Antwort & Erklärung

Richtige Antwort: B

CORS-Header sagen Browsern, welche Cross-Origin-Requests erlaubt sind. CSRF adressiert Cross-Site Request Forgery für credentialed Requests — verwandt, aber verschiedene Belange.

Warum die anderen Optionen falsch sind:

  • A) CSRF-Tokens ersetzen keine CORS-Response-Header für Browser-Cross-Origin-Zugriff.
  • C) Passwort-Encoding ist unabhängig von Browser-Origin-Policy.
  • D) Transaktionen sind unabhängig von HTTP CORS.

Merksatz: „Browser-Cross-Origin-API-Zugriff → CORS-Config; CSRF schützt Cookie-basierte mutierende Requests."

Weiterlernen: Buchkapitel

Frage 50​

Spring Security 6 nutzt authorizeHttpRequests in einem SecurityFilterChain-Bean.

Was bewirkt requestMatchers("/public/**").permitAll()?

  • A) Es deaktiviert alle Security-Filter global
  • B) Es verschlüsselt Responses für /public/**
  • C) Es verlangt ADMIN-Rolle für Public-Pfade
  • D) Es erlaubt unauthentifizierten Zugriff auf Pfade, die /public/** matchen, während andere Regeln verbleibende Endpoints sichern können
Antwort & Erklärung

Richtige Antwort: D

permitAll() gewährt Zugriff ohne Authentication für gematchte Requests. Andere requestMatchers-Regeln können Auth oder Rollen für verbleibende Pfade verlangen.

Warum die anderen Optionen falsch sind:

  • A) Security-Filter laufen weiter; Authorization erlaubt Zugriff für gematchte URLs.
  • B) Keine Response-Verschlüsselung ist impliziert.
  • C) permitAll ist das Gegenteil von ADMIN-Pflicht.

Merksatz: „permitAll() = anonymer Zugriff erlaubt für gematchte Pfade unter Authorization-Regeln."

Weiterlernen: Buchkapitel

Frage 51​

Ein Team will nur einen @RestController mit MockMvc testen, ohne die volle Datenbankschicht zu laden.

Welche Test-Slice-Annotation passt?


@WebMvcTest(OrderController.class)
class OrderControllerTest {
  @Autowired MockMvc mockMvc;
}
  • A) @WebMvcTest
  • B) @DataJpaTest
  • C) @SpringBootTest immer mit vollem Context
  • D) @JdbcTest für jeden Controller-Test
Antwort & Erklärung

Richtige Antwort: A

@WebMvcTest lädt MVC-Infrastruktur und den gezielten Web-Slice, mockt oder lässt volle Data-Layer-Beans weg. Kombiniere mit @MockBean für Controller-Abhängigkeiten.

Warum die anderen Optionen falsch sind:

  • B) @DataJpaTest fokussiert JPA/Repositories, nicht MVC-Controller.
  • C) Voller Context funktioniert, ist aber langsamer und nicht die Slice-fokussierte Wahl.
  • D) @JdbcTest testet JDBC-Komponenten, nicht REST-Controller.

Merksatz: „Controller-only MVC-Tests → @WebMvcTest + MockMvc."

Weiterlernen: Buchkapitel

Frage 52​

Ein @WebMvcTest muss den echten OrderService-Bean durch einen Stub im Test-Context ersetzen.

Welche Annotation fügt einen Bean im Spring-Test-Context hinzu oder ersetzt ihn?

  • A) Nur @Mock von Mockito auf einem Feld ohne Spring-Integration
  • B) Nur @InjectMocks
  • C) @MockBean auf einem Feld oder @Bean-Methode in der Test-Konfiguration
  • D) @SpyBean ist die einzige Option und ruft immer echte Methoden auf
Antwort & Erklärung

Richtige Antwort: C

@MockBean registriert einen Mockito-Mock/Stub im Spring ApplicationContext und ersetzt oder ergänzt Beans für Integration/Slice-Tests.

Warum die anderen Optionen falsch sind:

  • A) Plain @Mock publiziert keine Beans im Spring Context.
  • B) @InjectMocks konstruiert das Test-Subjekt, publiziert aber keine Mocks als Spring Beans.
  • D) @SpyBean wrappt echte Beans; @MockBean ist der Standard-Ersatz-Stub.

Merksatz: „Spring-Test-Context-Mock-Ersatz → @MockBean, nicht plain Mockito @Mock."

Weiterlernen: Buchkapitel

Frage 53​

Repository-Query-Methoden sollen gegen eine In-Memory-Datenbank mit JPA-Bootstrap, aber ohne Web-Schicht getestet werden.

Welche Annotation startet den richtigen Test-Slice?

  • A) @WebMvcTest
  • B) @DataJpaTest
  • C) Nur @JsonTest
  • D) @RestClientTest
Antwort & Erklärung

Richtige Antwort: B

@DataJpaTest konfiguriert JPA, typischerweise mit Embedded Database, und lädt Repository-Beans ohne vollen Application/Web-Stack.

Warum die anderen Optionen falsch sind:

  • A) @WebMvcTest schließt volle JPA-Auto-Config aus, außer was du mockst.
  • C) @JsonTest zielt nur auf JSON-Serialisierung.
  • D) @RestClientTest zielt auf REST Clients, nicht JPA Repositories.

Merksatz: „Repositories isoliert testen → @DataJpaTest mit Embedded DB."

Weiterlernen: Buchkapitel

Frage 54​

Ein Integrationstest muss den vollen Application Context starten und an einen zufälligen HTTP-Port für REST-Calls binden.

Welche @SpringBootTest-Konfiguration ist korrekt?


@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
class ApiIntegrationTest {
  @Autowired TestRestTemplate restTemplate;
}
  • A) webEnvironment = WebEnvironment.MOCK only
  • B) Kein webEnvironment-Attribut — Port ist immer fix 8080
  • C) @WebMvcTest mit @AutoConfigureMockMvc only
  • D) webEnvironment = WebEnvironment.RANDOM_PORT
Antwort & Erklärung

Richtige Antwort: D

WebEnvironment.RANDOM_PORT startet den Embedded Server auf zufälligem Port und ermöglicht TestRestTemplate/WebTestClient gegen einen echten Listener.

Warum die anderen Optionen falsch sind:

  • A) MOCK nutzt Mock-Servlet-Environment ohne echten Listening-Port.
  • B) Zufälliger Port braucht explizite RANDOM_PORT-Konfiguration.
  • C) @WebMvcTest ist ein Slice, kein volles Integration mit echtem Port-Binding.

Merksatz: „Volle Integration auf echtem Embedded Port → @SpringBootTest(RANDOM_PORT)."

Weiterlernen: Buchkapitel

Frage 55​

Ein @DataJpaTest modifiziert Daten in @Test-Methoden gegen eine gemeinsame Embedded Database.

Was ist das Default-Transaktionsverhalten für Spring-Boot-Tests mit @Transactional auf Klassenebene?

  • A) Jeder Test läuft in einer Transaktion, die nach dem Test standardmäßig zurückrollt und die DB sauber hält
  • B) Daten bleiben immer ohne Rollback über Tests hinweg persistent
  • C) Tests nutzen nie Transaktionen
  • D) Rollback erfolgt nur bei @SpringBootTest, nie bei Slice-Tests
Antwort & Erklärung

Richtige Antwort: A

Spring-Test-@Transactional auf Tests rollt nach jeder Testmethode standardmäßig zurück und isoliert DB-State. @Commit kann überschreiben.

Warum die anderen Optionen falsch sind:

  • B) Default-Test-Transaktion rollt zurück, außer @Commit oder explizite Persistenz.
  • C) Test-verwaltete Transaktionen sind üblich, besonders für Datentests.
  • D) @Transactional-Rollback gilt auch für Slice-Tests, wenn annotiert.

Merksatz: „Test-Klassen-@Transactional → Rollback nach jedem Test standardmäßig."

Weiterlernen: Buchkapitel

Frage 56​

Ein Entwickler wählt zwischen MockMvc und TestRestTemplate zum Testen eines gesicherten REST-Endpoints.

Welche Aussage unterscheidet sie am besten?

  • A) Sie sind identische APIs mit verschiedenen Package-Namen
  • B) MockMvc startet immer einen Netzwerk-Socket auf Port 443
  • C) MockMvc simuliert MVC-Dispatch in-process ohne echten HTTP-Server; TestRestTemplate sendet echte HTTP-Calls gegen einen laufenden Server
  • D) TestRestTemplate kann keine HTTP-Header senden
Antwort & Erklärung

Richtige Antwort: C

MockMvc testet Servlet/MVC-Stack im Speicher (ideal für @WebMvcTest). TestRestTemplate/WebTestClient treffen echte Endpoints auf Embedded- oder Real-Servern (RANDOM_PORT-Tests).

Warum die anderen Optionen falsch sind:

  • A) APIs und Runtime-Modelle unterscheiden sich deutlich.
  • B) MockMvc öffnet keine echten Netzwerk-Ports.
  • D) TestRestTemplate unterstützt Header, Entities und vollen HTTP-Exchange.

Merksatz: „In-Process MVC → MockMvc; echtes HTTP zum Embedded Server → TestRestTemplate/WebTestClient."

Weiterlernen: Buchkapitel

Frage 57​

Eine @Service-Klasse ruft ihre eigene @Transactional-Methode von einer anderen Methode in derselben Klasse auf.

Warum greift Transaction Advice beim internen Aufruf oft nicht?


@Service
public class TransferService {
  public void process() {
    doTransfer(); // interner Aufruf
  }

  @Transactional
  public void doTransfer() { ... }
}
  • A) Transaktionen funktionieren nie in @Service-Klassen
  • B) Spring-AOP-Proxies fangen externe Aufrufe ab; Self-Invocation umgeht den Proxy und überspringt Advice
  • C) Nur @Repository-Methoden können transaktional sein
  • D) Interne Aufrufe laufen immer automatisch in REQUIRES_NEW
Antwort & Erklärung

Richtige Antwort: B

Spring wendet @Transactional über Proxies an. Aufrufe über this innerhalb der Klasse umgehen den Proxy, sodass Advice nicht läuft. Fix durch Self-Proxy-Injection, Code verschieben oder AOP-Refactoring.

Warum die anderen Optionen falsch sind:

  • A) Transaktionen funktionieren, wenn Aufrufe über den Spring-Proxy laufen.
  • C) @Transactional wird auf Services und andere Spring Beans unterstützt.
  • D) Propagation wird bei Self-Invocation nicht auto-geändert; Advice wird einfach übersprungen.

Merksatz: „Self-Invocation überspringt den Proxy — @Transactional auf internen Aufrufen greift nicht."

Weiterlernen: Buchkapitel

Frage 58​

Eine Anwendung publiziert OrderPlacedEvent über ApplicationEventPublisher. Kein @Async-Listener ist konfiguriert.

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


@Service
public class BillingService {
  @Autowired ApplicationEventPublisher events;

  public void placeOrder() {
    events.publishEvent(new OrderPlacedEvent(...));
  }
}

@Component
class OrderAuditListener {
  @EventListener
  void onOrderPlaced(OrderPlacedEvent event) { }
}
  • A) Immer auf einem neuen Thread-Pool-Thread
  • B) Nur nach Server-Shutdown
  • C) Nur wenn @EnableScheduling vorhanden ist
  • D) Synchron auf dem publizierenden Thread, außer anders konfiguriert (z. B. @Async)
Antwort & Erklärung

Richtige Antwort: D

Standard-Spring-Event-Listener laufen synchron im Caller-Thread. @Async auf Listener-Methoden oder Async Event Multicaster ermöglicht asynchrone Zustellung.

Warum die anderen Optionen falsch sind:

  • A) Async-Zustellung braucht explizite Async-Konfiguration.
  • B) Events sind Runtime-Dispatch, nicht shutdown-getriggert.
  • C) Scheduling-Enablement ist unabhängig von Event-Listener-Threading.

Merksatz: „Default-Spring-Events sind synchron — async Listener brauchen @Async-Unterstützung."

Weiterlernen: Buchkapitel

Frage 59​

Eine Methode ist mit @Async annotiert, Aufrufe kehren aber sofort zurück, ohne Arbeit auf einem anderen Thread auszuführen.

Was fehlt am häufigsten?

  • A) @EnableAsync ist auf keiner @Configuration-Klasse aktiviert
  • B) @EnableWebMvc fehlt
  • C) Die Methode ist private, was für async erforderlich ist
  • D) JUnit 4 ist erforderlich
Antwort & Erklärung

Richtige Antwort: A

@Async braucht @EnableAsync, um Springs Async-Proxy/Executor-Infrastruktur zu konfigurieren. Public-Methoden, die über den Spring-Proxy aufgerufen werden, sind async-eligible.

Warum die anderen Optionen falsch sind:

  • B) Web-MVC-Enablement ist unabhängig von asynchroner Methodenausführung.
  • C) private-Methoden werden nicht für @Async geproxyt; public-Methoden sind erforderlich.
  • D) JUnit-Version steuert nicht Runtime-Async-Enablement.

Merksatz: „@Async braucht @EnableAsync und Aufrufe über den Spring-Proxy auf public-Methoden."

Weiterlernen: Buchkapitel

Frage 60​

Ein Scheduled Job soll den nächsten Lauf eine feste Zeit nach Ende des vorherigen starten — nicht in festen Wanduhr-Intervallen.

Welches @Scheduled-Attribut drückt dieses Verhalten aus?


@Component
public class ReconciliationJob {
  @Scheduled(fixedDelay = 5000)
  public void reconcile() { }
}
  • A) Nur cron = "*/1 * * * * *"
  • B) Nur initialDelay
  • C) fixedDelay — Verzögerung gemessen ab Ende der vorherigen Ausführung
  • D) fixedRate — Intervall gemessen ab Start jeder Ausführung
Antwort & Erklärung

Richtige Antwort: C

fixedDelay wartet nach Abschluss, bevor der nächste Lauf geplant wird. fixedRate plant in gleichmäßigem Takt ab Startzeiten, was bei langsamen Läufen überlappen kann.

Warum die anderen Optionen falsch sind:

  • A) Cron drückt Kalendermuster aus, nicht completion-basierte Delay-Semantik.
  • B) initialDelay betrifft nur das Timing der ersten Ausführung.
  • D) fixedRate misst von Start zu Start, nicht von Ende zu Start.

Merksatz: „Nach Ende warten → fixedDelay; gleichmäßiges Start-zu-Start-Intervall → fixedRate."

Weiterlernen: Buchkapitel

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