Zum Hauptinhalt springen

Mock Full 01 — 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-Monolith wird auf Spring migriert. Das Team will lose Kopplung zwischen Services, stößt aber immer wieder auf NullPointerException, wenn Collaborators nicht verdrahtet sind.

Welcher Spring-Mechanismus adressiert direkt das Problem, dass Objekte ihre eigenen Abhängigkeiten erzeugen und fehlschlagen, wenn Collaborators fehlen?

  • A) Nur Component Scanning
  • B) Bean-Lifecycle-Callbacks
  • C) Dependency Injection über den IoC-Container
  • D) Property-Placeholder-Auflösung
Antwort & Erklärung

Richtige Antwort: C

Dependency Injection (DI) ist das zentrale IoC-Muster, bei dem der Container Collaborators bereitstellt, statt dass Klassen new oder statische Lookups nutzen. Das löst enge Kopplung und stellt sicher, dass erforderliche Abhängigkeiten bei der Erstellung geliefert werden — genau das verhindert ad-hoc-null-Collaborators in einer Spring-Anwendung.

Warum die anderen Optionen falsch sind:

  • A) Component Scanning findet Beans, injiziert aber nicht von sich aus Abhängigkeiten in beliebige Objekte.
  • B) Lifecycle-Callbacks laufen, nachdem ein Bean existiert; sie ersetzen nicht die Verdrahtung von Abhängigkeiten.
  • D) Property-Placeholders injizieren Konfigurationswerte, keine beliebigen Objekt-Collaborators.

Merksatz: „DI heißt: Der Container verdrahtet Collaborators; Objekte erzeugen ihre Abhängigkeiten nicht mit new."

Weiterlernen: Buchkapitel

Frage 2​

Beim Startup-Debugging vergleicht ein Entwickler das Verhalten von BeanFactory und ApplicationContext in einer Web-Anwendung.

Welche Aussage über ApplicationContext im Vergleich zu BeanFactory ist korrekt?


@Configuration
public class AppConfig {
    @Bean
    public PaymentService paymentService() {
        return new PaymentService();
    }
}
  • A) BeanFactory initialisiert alle Singleton-Beans beim Refresh eager, ApplicationContext ist lazy
  • B) Nur BeanFactory unterstützt die Verarbeitung von @Configuration-Klassen
  • C) ApplicationContext kann keine Bean-Definitionen aus Java-Konfiguration laden
  • D) ApplicationContext ist eine Obermenge mit Enterprise-Features wie Event-Publikation und Internationalisierung
Antwort & Erklärung

Richtige Antwort: D

ApplicationContext erweitert BeanFactory und fügt höherwertige Container-Fähigkeiten hinzu — unter anderem Application-Event-Propagation, MessageSource-Zugriff, Resource-Loading-Muster und automatische BeanPostProcessor-Registrierung. BeanFactory ist der minimale Vertrag; ApplicationContext nutzt Spring Boot in der Praxis.

Warum die anderen Optionen falsch sind:

  • A) Es ist eher umgekehrt: ApplicationContext erzeugt Singletons standardmäßig eager beim Refresh.
  • B) @Configuration-Verarbeitung übernehmen Configuration-Class-Post-Processor, die im ApplicationContext registriert sind.
  • C) ApplicationContext unterstützt @Configuration und @Bean-Definitionen vollständig.

Merksatz: „ApplicationContext = BeanFactory plus Events, i18n und reichere Startup-Integration."

Weiterlernen: Buchkapitel

Frage 3​

Eine Bean-Definition gibt die Klasse com.example.ReportService und den Scope singleton an. Zwei verschiedene @Autowired-Felder in derselben Anwendung erhalten beide einen ReportService. Was ist garantiert?


@Service
public class ReportService { }

@Autowired ReportService a;
@Autowired ReportService b; // dieselbe Instanz wie a
  • A) Jeder Injection Point erhält eine eigene Instanz, weil die Felder getrennt sind
  • B) Pro Injection Point wird eine neue Instanz erzeugt
  • C) Prototype-Scope gilt implizit, sobald @Autowired verwendet wird
  • D) Beide Injection Points erhalten dieselbe Singleton-Instanz, die der Container verwaltet
Antwort & Erklärung

Richtige Antwort: D

Standard-Singleton-Scope bedeutet eine gemeinsame Instanz pro Bean-Definition im Container. Jeder Injection Point, der auf diesen Bean-Namen/-Typ verweist, erhält dieselbe Objektreferenz — außer es wird ein explizit engerer Scope oder Provider-Indirektion genutzt.

Warum die anderen Optionen falsch sind:

  • A) Getrennte Felder bedeuten unter Singleton-Scope keine getrennten Bean-Instanzen.
  • B) Singleton-Beans werden nicht pro Injection Site erzeugt.
  • C) @Autowired ändert den Scope nicht; der Scope kommt aus der Bean-Definition.

Merksatz: „Singleton = eine container-verwaltete Instanz, die alle Injection Points teilen."

Weiterlernen: Buchkapitel

Frage 4​

Der Konstruktor von OrderService benötigt ein PaymentGateway. Das Team fügt @Autowired am Konstruktor hinzu, nachdem ein zweiter Konstruktor fürs Testen eingeführt wurde.

Was passiert, wenn OrderService zwei Konstruktoren hat und nur einer mit @Autowired annotiert ist?


@Service
public class OrderService {
    private final PaymentGateway gateway;

    public OrderService(PaymentGateway gateway) {
        this.gateway = gateway;
    }

    public OrderService() {
        this.gateway = null;
    }
}
  • A) Spring wählt immer den No-Arg-Konstruktor
  • B) Spring nutzt den @Autowired-Konstruktor für Dependency Injection
  • C) Spring bricht den Startup ab, weil mehrere Konstruktoren nicht erlaubt sind
  • D) Spring injiziert stattdessen in Felder, wenn mehrere Konstruktoren existieren
Antwort & Erklärung

Richtige Antwort: B

Bei mehreren Konstruktoren kann Spring 4.3+ einen einzelnen Konstruktor ohne Annotation autowiren, wenn er der einzige ist — gibt es mehr als einen, musst du den gewünschten mit @Autowired markieren (oder in älteren Versionen @Required nutzen). Der annotierte Konstruktor wird zum Injection Target.

Warum die anderen Optionen falsch sind:

  • A) Bei mehreren Konstruktoren defaultet Spring nicht auf No-Arg, außer er ist der einzige autowirable Kandidat.
  • C) Mehrere Konstruktoren sind erlaubt, wenn der gewünschte explizit ausgewählt wird.
  • D) Konstruktor-Ambiguität wird durch Konstruktor-Auswahl gelöst, nicht durch automatische Feld-Injection.

Merksatz: „Mehrere Konstruktoren: Den Injection-Konstruktor mit @Autowired markieren."

Weiterlernen: Buchkapitel

Frage 5​

Welcher Injection-Stil ist in Spring allgemein bevorzugt für erforderliche, unveränderliche Abhängigkeiten und gute Testbarkeit?


@Service
public class InvoiceService {
    private final TaxService taxService;
    public InvoiceService(TaxService taxService) {
        this.taxService = taxService;
    }
}
  • A) Feld-Injection mit @Autowired
  • B) Nur Setter-Injection
  • C) Konstruktor-Injection
  • D) Statischer Factory-Lookup aus ApplicationContextHolder
Antwort & Erklärung

Richtige Antwort: C

Konstruktor-Injection macht Abhängigkeiten explizit, ermöglicht unveränderliche Felder, vereinfacht Unit-Tests ohne Spring und vermeidet versteckte Feld-Abhängigkeiten. Spring-Dokumentation und Prüfungsmaterial behandeln Konstruktor-Injection durchgängig als bevorzugten Stil für erforderliche Collaborators.

Warum die anderen Optionen falsch sind:

  • A) Feld-Injection verbirgt Abhängigkeiten und erschwert Tests.
  • B) Setter-Injection ist für optionale Abhängigkeiten sinnvoll, aber nicht die allgemeine Best Practice für erforderliche.
  • D) Statische Context-Lookups sind ein Anti-Pattern mit enger Framework-Kopplung.

Merksatz: „Konstruktor-Injection bevorzugen für erforderliche, unveränderliche Collaborators."

Weiterlernen: Buchkapitel

Frage 6​

Ein Bibliotheksmodul unter com.vendor.integration wird hinzugefügt, aber Beans in diesem Package werden zur Laufzeit nicht erzeugt.

Die Hauptanwendungsklasse liegt in com.example.app und nutzt @SpringBootApplication. Beans in com.vendor.integration sind mit @Component annotiert, registrieren sich aber nie. Was ist die wahrscheinlichste Ursache?


@SpringBootApplication
public class DemoApplication {
    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}
  • A) Component Scanning startet im Package der @SpringBootApplication-Klasse und schließt com.vendor.integration standardmäßig nicht ein
  • B) @Component kann außerhalb des Hauptanwendungs-Packages nicht verwendet werden
  • C) Spring Boot deaktiviert Scanning, außer spring.scan.enabled=true
  • D) Nur @Bean-Methoden können Beans außerhalb des Haupt-Packages registrieren
Antwort & Erklärung

Richtige Antwort: A

@SpringBootApplication kombiniert @Configuration, @EnableAutoConfiguration und @ComponentScan mit Standard-Basis-Package gleich dem Package der deklarierenden Klasse. Klassen außerhalb dieses Package-Baums werden nicht gescannt, außer du ergänzt @ComponentScan basePackages oder nutzt @Import.

Warum die anderen Optionen falsch sind:

  • B) @Component funktioniert in jedem gescannten Package.
  • C) Es gibt keinen Standard-Schalter spring.scan.enabled; Scanning ist über @SpringBootApplication standardmäßig aktiv.
  • D) @Component Scanning ist der normale Weg, Beans außerhalb des Haupt-Packages zu registrieren, wenn die Scan-Pfade sie einschließen.

Merksatz: „@SpringBootApplication scannt nur sein eigenes Package und Unterpackages — außer du erweiterst @ComponentScan."

Weiterlernen: Buchkapitel

Frage 7​

Was bewirkt @Primary auf einem Bean vom Typ NotificationSender, wenn mehrere NotificationSender-Beans existieren?


@Bean @Primary
public NotificationSender emailSender() { return new EmailSender(); }

@Bean
public NotificationSender smsSender() { return new SmsSender(); }
  • A) Es markiert den Bean als einzige erlaubte Implementierung und deaktiviert andere
  • B) Es gibt dem Bean höhere @Order für AOP-Advice
  • C) Es ändert den Bean-Scope auf Singleton
  • D) Es macht diesen Bean zum bevorzugten Kandidaten beim Autowiring nach Typ ohne @Qualifier
Antwort & Erklärung

Richtige Antwort: D

@Primary löst Ambiguität, wenn mehrere Beans zu einem Injection-Point-Typ passen. Ohne @Qualifier wird der Primary Bean gewählt. Andere Beans bleiben gültig und können weiterhin mit @Qualifier oder @Resource-Name injiziert werden.

Warum die anderen Optionen falsch sind:

  • A) @Primary deaktiviert andere Beans nicht.
  • B) @Order betrifft geordnete Listen und manche Infrastruktur-Reihenfolge, nicht @Primary-Auswahl.
  • C) @Primary ändert den Scope nicht.

Merksatz: „@Primary bricht Typ-Ambiguität; @Qualifier wählt explizit einen bestimmten Bean."

Weiterlernen: Buchkapitel

Frage 8​

Ein Reporting-Modul braucht die neueste ExchangeRateService-Implementierung, aber zwei Beans implementieren das Interface.

Ein Feld ist als @Autowired ExchangeRateService service deklariert. Es existieren zwei Beans: exchangeRateServiceLegacy und exchangeRateServiceV2. Wie injizierst du explizit exchangeRateServiceV2?

  • A) @Lazy am Feld hinzufügen
  • B) @Qualifier("exchangeRateServiceV2") oder gleichwertigen Bean-Namen-Qualifier nutzen
  • C) exchangeRateServiceV2 mit @Controller markieren
  • D) @Autowired entfernen und in @PostConstruct manuell getBean aufrufen
Antwort & Erklärung

Richtige Antwort: B

Wenn mehrere Beans zu einem Typ passen, wählt @Qualifier (oder @Resource mit Name) den gewünschten Bean nach Name oder Custom-Qualifier-Annotation. Das ist die idiomatische Spring-Lösung für explizite Disambiguierung.

Warum die anderen Optionen falsch sind:

  • A) @Lazy verzögert nur die Initialisierung; es wählt nicht zwischen Kandidaten.
  • C) Stereotype-Annotationen lösen Injection-Ambiguität nicht von selbst.
  • D) Manuelles getBean funktioniert, ist aber nicht der deklarative Injection-Ansatz, den die Prüfung erwartet.

Merksatz: „Mehrere Beans eines Typs: @Qualifier oder @Primary nutzen."

Weiterlernen: Buchkapitel

Frage 9​

Welche Aussage über die Required-Semantik von @Autowired ist standardmäßig korrekt?

  • A) Injection ist optional, außer @Autowired(required = false) ist gesetzt
  • B) Primitive Abhängigkeiten sind immer optional
  • C) Alle Abhängigkeiten werden unabhängig von der Annotation lazy initialisiert
  • D) Wenn kein passender Bean existiert, schlägt der Context-Start mit NoSuchBeanDefinitionException fehl
Antwort & Erklärung

Richtige Antwort: D

Standardmäßig ist @Autowired required=true. Kann Spring keinen eindeutigen passenden Bean für einen erforderlichen Injection Point auflösen, schlägt die ApplicationContext-Initialisierung mit NoSuchBeanDefinitionException oder verwandter Ambiguitäts-Exception fehl.

Warum die anderen Optionen falsch sind:

  • A) Required ist standardmäßig true; optionale Injection braucht required=false.
  • B) Fehlende Primitive-Collaborators führen trotzdem zum Fehler, weil null nicht injiziert werden kann.
  • C) @Autowired erzwingt keine Lazy-Initialisierung der Abhängigkeit.

Merksatz: „Standard-@Autowired ist required; required=false nur für optionale Collaborators."

Weiterlernen: Buchkapitel

Frage 10​

Ein Team diskutiert, ob XML, Java-Config oder Component Scanning für eine kleine interne Utility-Bibliothek genutzt werden soll, die von Spring-Boot-Apps konsumiert wird.

Welcher Ansatz lässt Spring Klassen mit Stereotype-Annotationen entdecken, ohne für jede Klasse explizite @Bean-Methoden zu schreiben?


@Service
public class PricingService { }
  • A) Jede Klasse in beans.xml deklarieren
  • B) BeanFactoryPostProcessor manuell für jeden Typ nutzen
  • C) Component Scanning mit @Component, @Service, @Repository oder @Controller
  • D) Klassen nur über @PropertySource registrieren
Antwort & Erklärung

Richtige Antwort: C

Component Scanning erkennt Classpath-Kandidaten mit Stereotype-Annotationen und registriert sie automatisch als Bean-Definitionen. Das spart Boilerplate-@Bean-Factory-Methoden für einfache Klassen.

Warum die anderen Optionen falsch sind:

  • A) XML kann Beans deklarieren, entdeckt aber annotierte Klassen nicht automatisch, außer component-scan ist konfiguriert.
  • B) BeanFactoryPostProcessor ist ein Low-Level-Extension Point, nicht der normale Discovery-Mechanismus.
  • D) @PropertySource lädt Properties, keine Komponenten-Klassen.

Merksatz: „Stereotype-Annotationen plus Component Scanning registrieren Beans automatisch."

Weiterlernen: Buchkapitel

Frage 11​

In einer @Configuration-Klasse: Was sagt @Bean auf einer Methode Spring?


@Configuration
public class AppConfig {
    @Bean
    public Clock systemClock() {
        return Clock.systemUTC();
    }
}
  • A) Den Rückgabetyp sofort instanziieren, wenn die Klasse geladen wird
  • B) Den Rückgabewert der Methode als vom Container verwalteten Bean registrieren
  • C) Die Methode als REST-Endpoint bereitstellen
  • D) Die Methode bei jedem HTTP-Request ausführen
Antwort & Erklärung

Richtige Antwort: B

@Bean-Methoden werden durch Configuration-Class-Enhancement verarbeitet, sodass Spring sie aufruft, um Beans im Container zu registrieren. Der Container steuert Lifecycle und Injection des zurückgegebenen Objekts.

Warum die anderen Optionen falsch sind:

  • A) Das JVM-Laden der Klasse erzeugt den Bean nicht; das passiert beim Context-Refresh durch den Container.
  • C) REST-Exposition braucht Web-Mapping-Annotationen, nicht @Bean.
  • D) @Bean hat kein Request-Scope-Verhalten von sich aus.

Merksatz: „@Bean-Methode = Factory-Methode, deren Rückgabewert ein Spring Bean wird."

Weiterlernen: Buchkapitel

Frage 12​

Ein Payment-Client soll in Nicht-Produktion auf Sandbox zeigen und bei aktivem Profil prod auf die Produktions-URL.

Welche Kombination ist der idiomatische Weg, unterschiedliche PaymentClient-Beans pro Umgebung bereitzustellen?


@Bean
@Profile("prod")
public PaymentClient prodClient() { return new ProdPaymentClient(); }

@Bean
@Profile("!prod")
public PaymentClient sandboxClient() { return new SandboxPaymentClient(); }
  • A) Zwei @Bean-Methoden mit @Profile-Bedingungen für verschiedene Umgebungen
  • B) Ein Bean und manuelle if-Abfragen in main
  • C) Scope nur auf Prototype ändern
  • D) @Order auf beiden Beans ohne Profile
Antwort & Erklärung

Richtige Antwort: A

@Profile registriert Bean-Definitionen bedingt basierend auf aktiven Profilen. Das hält umgebungsspezifische Verdrahtung deklarativ und integriert sauber mit Spring-Boot-Profil-Aktivierung über Properties oder Umgebungsvariablen.

Warum die anderen Optionen falsch sind:

  • B) Manuelles Branching in main umgeht den Container und ist nicht idiomatisch.
  • C) Prototype-Scope erzeugt neue Instanzen, wählt aber keine umgebungsspezifischen Implementierungen.
  • D) @Order aktiviert keine Beans nach Umgebung.

Merksatz: „@Profile nutzen, um umgebungsspezifische Beans deklarativ zu registrieren."

Weiterlernen: Buchkapitel

Frage 13​

Was ermöglicht @ConfigurationProperties(prefix = "app.mail") auf einer Klasse primär?


@ConfigurationProperties(prefix = "app.mail")
public record MailProperties(String host, int port) {}
  • A) Eine JPA-Entity, die auf die Mail-Tabelle gemappt ist
  • B) Methoden-Level-Transaktionsmanagement für Mail-Code
  • C) Binden externer Konfigurations-Properties mit dem Präfix app.mail auf die Klassenfelder
  • D) Classpath-Scanning nur für Mail-Templates
Antwort & Erklärung

Richtige Antwort: C

@ConfigurationProperties bindet strukturierte Konfiguration aus Property-Dateien, Umgebungsvariablen und anderen PropertySources auf ein typisiertes Objekt. Das ist besser als viele separate @Value-Injections für gruppierte Einstellungen.

Warum die anderen Optionen falsch sind:

  • A) Hat nichts mit JPA-Entity-Mapping zu tun.
  • B) Transaktionsmanagement kommt von @EnableTransactionManagement, nicht von @ConfigurationProperties.
  • D) Führt kein Template-Classpath-Scanning durch.

Merksatz: „@ConfigurationProperties gruppiert und bindet externe Config in einen typisierten Bean."

Weiterlernen: Buchkapitel

Frage 14​

Ein Singleton DashboardService injiziert einen request-scoped UserContext-Bean. Nutzer berichten, alle Requests sehen dieselben User-Daten.

Was ist die korrekte Lösung, wenn ein Singleton-Bean pro HTTP-Request einen frischen UserContext braucht?

  • A) DashboardService nur auf Prototype-Scope ändern
  • B) UserContext mit @RequestScope markieren und einen Proxy in den Singleton injizieren (scoped-proxy)
  • C) UserContext manuell in statischem ThreadLocal speichern ohne Spring-Unterstützung
  • D) Singleton-Scope global in application.properties deaktivieren
Antwort & Erklärung

Richtige Antwort: B

Ein kürzer lebender Scoped Bean, der in einen länger lebenden Singleton injiziert wird, braucht einen Scoped Proxy, damit der Singleton einen Proxy hält, der pro Request an die aktuelle Scope-Instanz delegiert. Spring bietet das über @Scope(proxyMode = ScopedProxyMode.TARGET_CLASS) oder @RequestScope auf einem Bean, der über Injection-Proxy konsumiert wird.

Warum die anderen Optionen falsch sind:

  • A) Den Singleton zu Prototype zu machen erzeugt viele Service-Instanzen und bricht meist die Architektur.
  • C) Manuelles statisches ThreadLocal umgeht Spring-Scope-Management und ist hier ein Anti-Pattern.
  • D) Singleton ist der Default und kann so nicht global deaktiviert werden.

Merksatz: „Singleton, der Request/Session-Bean injiziert, braucht Scoped Proxy."

Weiterlernen: Buchkapitel

Frage 15​

Welcher Bean-Scope erzeugt bei jeder Anforderung vom Container eine neue Instanz?

  • A) Singleton
  • B) Prototype
  • C) Request
  • D) Application
Antwort & Erklärung

Richtige Antwort: B

Prototype-Scope sagt Spring, bei jedem getBean oder Injection-Point-Auflösung — je nach Kontext — eine neue Bean-Instanz zu erzeugen, anders als Singleton mit einer gemeinsamen Instanz.

Warum die anderen Optionen falsch sind:

  • A) Singleton liefert dieselbe gemeinsame Instanz.
  • C) Request-Scope ist eine Instanz pro HTTP-Request, nicht pro Injection.
  • D) Application-Scope ist eine Instanz pro ServletContext in Web-Apps.

Merksatz: „Prototype = neue Instanz pro Abruf/Injection-Zyklus."

Weiterlernen: Buchkapitel

Frage 16​

Operations aktiviert spring.profiles.active=prod,cloud beim Deployment. Einige Beans laden weiterhin aus dem Default-Profil-Set.

Wie wertet Spring @Profile("prod") auf einer @Bean-Methode aus, wenn die aktiven Profile prod und cloud sind?

  • A) Der Bean wird nicht registriert, weil mehrere aktive Profile @Profile ungültig machen
  • B) Der Bean wird registriert, weil prod zu den aktiven Profilen gehört
  • C) Der Bean registriert sich nur, wenn cloud auch in @Profile genannt ist
  • D) Profile müssen sich gegenseitig ausschließen, sonst schlägt der Startup fehl
Antwort & Erklärung

Richtige Antwort: B

Mehrere aktive Profile koexistieren. Eine @Profile-Bedingung matcht, wenn ein gelisteter Profil-Ausdruck erfüllt ist. @Profile("prod") matcht, wenn prod aktiv ist — unabhängig von zusätzlichen Profilen wie cloud.

Warum die anderen Optionen falsch sind:

  • A) Mehrere aktive Profile sind normal und unterstützt.
  • C) @Profile("prod") verlangt nicht, dass jedes aktive Profil in der Annotation steht.
  • D) Profile müssen sich nicht gegenseitig ausschließen.

Merksatz: „Mehrere Profile können aktiv sein; @Profile matcht, wenn sein Ausdruck erfüllt ist."

Weiterlernen: Buchkapitel

Frage 17​

Was ist der Zweck eines BeanPostProcessor im Spring-Container-Lifecycle?

  • A) PropertySource-Dateien zur Laufzeit ersetzen
  • B) Bean-Initialisierung abfangen und Beans vor und nach Initialisierungs-Callbacks modifizieren oder wrappen
  • C) @Configuration-Klassen schneller nach Bytecode kompilieren
  • D) HTTP-Requests auf Controller-Methoden mappen
Antwort & Erklärung

Richtige Antwort: B

BeanPostProcessor ist ein Extension Point, der vor und nach der Bean-Initialisierung für jeden Bean aufgerufen wird. Spring nutzt viele interne BPPs für Annotation-Verarbeitung, AOP-Proxy-Erzeugung und @Autowired-Injection.

Warum die anderen Optionen falsch sind:

  • A) PropertySource-Änderungen übernehmen Environment und PropertySource-Mechanismen.
  • C) Configuration-Class-Verarbeitung nutzt ConfigurationClassPostProcessor, einen spezialisierten BPP — der generische BPP-Zweck ist Bean-Anpassung.
  • D) Handler Mapping ist Teil von Spring MVC, nicht BeanPostProcessor.

Merksatz: „BeanPostProcessor hakt vor/nach Bean-Initialisierung für jeden Bean ein."

Weiterlernen: Buchkapitel

Frage 18​

Eine @Configuration-Klasse definiert zwei @Bean-Methoden, wobei eine die andere direkt innerhalb derselben Klasse aufruft.

Was macht Spring bei @Bean-Methoden-Inter-Calls innerhalb derselben @Configuration-Klasse?


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

    @Bean
    public TaxCalculator taxCalculator() {
        return new TaxCalculator();
    }
}
  • A) Jeder Aufruf erzeugt ein frisches Objekt, weil es normale Java-Methodenaufrufe sind
  • B) Spring proxyt die Configuration-Klasse, sodass @Bean-Methodenaufrufe über den Container laufen und Singleton-Semantik respektieren
  • C) Inter-Calls sind verboten und verursachen BeanCurrentlyInCreationException
  • D) Nur XML-Konfiguration kann Beans zwischen Factory-Methoden teilen
Antwort & Erklärung

Richtige Antwort: B

Vollständige @Configuration-Klassen werden enhanced, sodass Inter-Bean-Methodenaufrufe über den Container geproxyt werden. Das stellt sicher, dass Singleton-Beans wiederverwendet werden, statt versehentlich durch direkte Java-Aufrufe neu erzeugt zu werden.

Warum die anderen Optionen falsch sind:

  • A) Plain @Configuration ohne Full Mode würde Beans neu erzeugen, aber Full @Configuration verhindert das per Proxy.
  • C) Inter-Calls sind by Design unterstützt.
  • D) Java @Configuration ist der Standardansatz für zusammengehörige @Bean-Methoden.

Merksatz: „Full @Configuration proxyt @Bean-Methodenaufrufe, damit Singletons Singleton bleiben."

Weiterlernen: Buchkapitel

Frage 19​

Welche drei Annotationen sind in @SpringBootApplication meta-komponiert?


@SpringBootApplication
public class ShopApplication {
    public static void main(String[] args) {
        SpringApplication.run(ShopApplication.class, args);
    }
}
  • A) @EnableWebMvc, @EnableJpaRepositories, @EnableScheduling
  • B) @Controller, @Service, @Repository
  • C) @Transactional, @Validated, @CrossOrigin
  • D) @SpringBootConfiguration, @EnableAutoConfiguration, @ComponentScan
Antwort & Erklärung

Richtige Antwort: D

@SpringBootApplication kombiniert @SpringBootConfiguration (spezialisierte @Configuration), @EnableAutoConfiguration und @ComponentScan (mit optionalen Attributen). Das ist die Bootstrap-Annotation für Spring-Boot-Apps.

Warum die anderen Optionen falsch sind:

  • A) Das sind separate Opt-in-Annotationen, nicht Teil von @SpringBootApplication.
  • B) Stereotype-Annotationen sind nicht in @SpringBootApplication meta-komponiert.
  • C) Diese Annotationen dienen anderen Belangen und sind nicht das Boot-Bootstrap-Trio.

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

Weiterlernen: Buchkapitel

Frage 20​

Ein Team fügt spring-boot-starter-data-jpa hinzu, will aber einen eigenen DataSource-Bean aus Firmenbibliothekscode bereitstellen.

Wenn du deinen eigenen DataSource-@Bean definierst, was macht Spring-Boot-Auto-Configuration typischerweise?

  • A) Es schlägt fehl, weil zwei DataSource-Beans nie erlaubt sind
  • B) Es tritt zurück und konfiguriert keine Default-DataSource
  • C) Es erzeugt trotzdem immer die Default-HikariCP-DataSource
  • D) Es löscht den Custom Bean und behält nur den auto-konfigurierten
Antwort & Erklärung

Richtige Antwort: B

Spring-Boot-Auto-Configuration nutzt @ConditionalOnMissingBean, sodass benutzerdefinierte Beans Vorrang haben. Wenn du deine eigene DataSource bereitstellst, tritt DataSource-Auto-Configuration zurück — das Back-off-Muster wird häufig geprüft.

Warum die anderen Optionen falsch sind:

  • A) Mehrere Definitionen sind erlaubt, wenn Auto-Config zurücktritt.
  • C) Auto-Config respektiert bestehende User-Beans über Missing-Bean-Bedingungen.
  • D) Spring entfernt niemals still User-Beans.

Merksatz: „User-@Bean eines Typs lässt passende Auto-Configuration zurücktreten."

Weiterlernen: Buchkapitel

Frage 21​

Welche Property hilft, einen Bericht über Auto-Configuration-Entscheidungen zu erzeugen — was gematcht hat und was nicht?


# application.properties
debug=true
  • A) spring.main.banner-mode=off
  • B) logging.level.root=ERROR
  • C) debug=true
  • D) spring.jpa.show-sql=true
Antwort & Erklärung

Richtige Antwort: C

debug=true (oder --debug) aktiviert den Auto-Configuration-Report beim Startup und in den Logs mit positiven und negativen Matches. Das ist das Hauptwerkzeug, um zu verstehen, warum eine Boot-Auto-Config angewendet wurde oder nicht.

Warum die anderen Optionen falsch sind:

  • A) Banner-Mode betrifft nur das Startup-Banner.
  • B) Root-Log-Level erzeugt den Condition-Evaluation-Report nicht von selbst.
  • D) show-sql loggt SQL-Statements, nicht Auto-Configuration-Bedingungen.

Merksatz: „debug=true druckt den Auto-Configuration-Condition-Evaluation-Report."

Weiterlernen: Buchkapitel

Frage 22​

Ein Microservice stellt Management-Endpoints auf einem separaten Port für das Platform-Team bereit.

Welche Konfiguration verschiebt Actuator-HTTP-Endpoints auf Port 9090, während die Haupt-App auf 8080 bleibt?


management.server.port=9090
  • A) Nur server.port=9090
  • B) Nur management.endpoints.web.exposure.include=*
  • C) spring.application.name=actuator
  • D) management.server.port=9090 auf einem separaten Management-Listener
Antwort & Erklärung

Richtige Antwort: D

management.server.port erzeugt einen separaten Management-Server/Port für Actuator-Endpoints in Servlet-basierten Apps und ermöglicht Netzwerk-Isolation vom Hauptanwendungs-Port (server.port).

Warum die anderen Optionen falsch sind:

  • A) server.port verschiebt die Hauptanwendung, nicht nur Actuator.
  • B) Exposure-Einstellungen steuern, welche Endpoints web-sichtbar sind, nicht den Port.
  • C) Application Name bindet Actuator nicht an einen anderen Port.

Merksatz: „management.server.port betreibt Actuator auf eigenem HTTP-Port."

Weiterlernen: Buchkapitel

Frage 23​

Standardmäßig in Spring Boot 2.x/3.x: Welcher Actuator-Endpoint ist über HTTP ohne zusätzliche Konfiguration exponiert?

  • A) env
  • B) beans
  • C) health
  • D) shutdown
Antwort & Erklärung

Richtige Antwort: C

Standard-Web-Exposure umfasst historisch nur health (und info in manchen Versionen mit versteckten Details). Sensible Endpoints wie env, beans und shutdown brauchen explizite Exposure-Konfiguration aus Sicherheitsgründen.

Warum die anderen Optionen falsch sind:

  • A) env ist standardmäßig nicht über Web exponiert.
  • B) beans ist nicht im Default-Web-Exposure-Set.
  • D) shutdown ist deaktiviert und standardmäßig nicht exponiert.

Merksatz: „Standardmäßig exponierter Actuator-Web-Endpoint ist health, außer du erweiterst die Exposure."

Weiterlernen: Buchkapitel

Frage 24​

Produktions-Health-Checks müssen DOWN melden, wenn die App ihre erforderliche Datenbank nicht erreicht, die JVM aber trotzdem starten.

Welcher Ansatz integriert Datenbank-Verfügbarkeit korrekt in den Application-Health-Endpoint?

  • A) Eigene main-Methode mit try/catch nur um SpringApplication.run
  • B) Auf HealthContributor oder DataSource-Health-Indicator-Auto-Configuration für den Health-Endpoint vertrauen
  • C) Alle Actuator-Endpoints in Produktion deaktivieren
  • D) @PostConstruct in jeder Repository-Klasse nutzen
Antwort & Erklärung

Richtige Antwort: B

Spring-Boot-Actuator-Health gruppiert Infrastruktur-Checks über HealthContributor-Beans. DataSourceHealthContributor-Auto-Configuration meldet Datenbankstatus auf /actuator/health, den Orchestratoren nutzen können — ohne Custom-Shutdown-Logik.

Warum die anderen Optionen falsch sind:

  • A) try/catch in main erzeugt keine strukturierten Health-Endpoint-Ergebnisse.
  • C) Actuator deaktivieren entfernt das Standard-Health-Signal, das Operatoren erwarten.
  • D) Repository-@PostConstruct integriert sich nicht in Actuator-Health-Aggregation.

Merksatz: „Health Contributors aggregieren Komponentenstatus in /actuator/health."

Weiterlernen: Buchkapitel

Frage 25​

Was ist der Hauptzweck von Spring-Boot-Startern wie spring-boot-starter-web?


<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-web</artifactId>
</dependency>
  • A) Sie ersetzen den ApplicationContext
  • B) Sie schreiben automatisch Controller-Code aus OpenAPI-Dateien
  • C) Sie deaktivieren Auto-Configuration für minimale Apps
  • D) Sie bündeln kuratierte Dependencies mit Versionen, die durch spring-boot-dependencies-BOM abgestimmt sind
Antwort & Erklärung

Richtige Antwort: D

Starter sind Dependency-Deskriptoren, die eine sinnvolle Bibliotheksmenge mit vom Boot-BOM verwalteten Versionen ziehen. Sie reduzieren manuelle Dependency-Verdrahtung und bleiben mit Boot-Auto-Configuration kompatibel.

Warum die anderen Optionen falsch sind:

  • A) Der Container verwaltet weiterhin Beans; Starter betreffen nur Classpath-Dependencies.
  • B) Starter generieren keinen Anwendungscode.
  • C) Starter aktivieren meist verwandte Auto-Configuration, wenn sie im Classpath sind.

Merksatz: „Starter = kuratierte Dependencies mit BOM-verwalteten Versionen."

Weiterlernen: Buchkapitel

Frage 26​

Der Startup ist langsam und das Team vermutet, dass ungenutzte Beans trotzdem eager initialisiert werden.

Welches Spring-Boot-Feature verzögert die Erzeugung von Singleton-Beans bis zur ersten Nutzung?

  • A) spring.main.lazy-initialization=true
  • B) @RefreshScope auf jedem Bean
  • C) Nur spring.jpa.defer-datasource-initialization
  • D) server.tomcat.max-threads=1
Antwort & Erklärung

Richtige Antwort: A

Globale Lazy Initialization sagt dem Application Context, Singleton-Beans bei erster Anforderung statt beim Refresh zu erzeugen. Das kann den Startup verkürzen, wenn viele Beans früh ungenutzt sind — mit Trade-offs beim Fail-Fast-Timing.

Warum die anderen Optionen falsch sind:

  • B) @RefreshScope ist für Cloud-refreshable Beans, nicht allgemeines Lazy Startup.
  • C) Defer Datasource Initialization betrifft SQL-Init-Timing, nicht alle Bean-Erzeugung.
  • D) Tomcat-Thread-Einstellungen steuern nicht Bean-Initialisierungs-Timing.

Merksatz: „spring.main.lazy-initialization=true erzeugt Singletons bei erster Nutzung."

Weiterlernen: Buchkapitel

Frage 27​

Eine Klasse implementiert ApplicationRunner und ist als Spring Bean registriert. Wann wird ihre run-Methode ausgeführt?

  • A) Bevor der ApplicationContext erzeugt wird
  • B) Nach Context-Refresh und Anwendungsstart, als Teil der Startup-Callbacks
  • C) Bei jedem HTTP-Request nach DispatcherServlet-Mapping
  • D) Nur wenn actuator/refresh aufgerufen wird
Antwort & Erklärung

Richtige Antwort: B

ApplicationRunner- und CommandLineRunner-Beans laufen nach abgeschlossenem Context-Startup — ein sicherer Zeitpunkt, wenn die Anwendung bereit ist. Spring Boot sammelt und ruft sie beim Startup auf.

Warum die anderen Optionen falsch sind:

  • A) Der Context muss existieren und refreshed sein.
  • C) Runner sind Startup-Hooks, keine per-Request-Handler.
  • D) Refresh-Endpoints sind unabhängig von standardmäßiger ApplicationRunner-Ausführung.

Merksatz: „ApplicationRunner läuft einmal, nachdem der Spring Context gestartet ist."

Weiterlernen: Buchkapitel

Frage 28​

Eine Auto-Config-Klasse soll nur gelten, wenn die Klasse org.apache.catalina.startup.Tomcat im Classpath ist.

Welche Condition-Annotation drückt Classpath-basierte Auto-Configuration-Guards aus?

  • A) @ConditionalOnBean(Tomcat.class)
  • B) Nur @ConditionalOnWebApplication
  • C) @Profile("tomcat")
  • D) @ConditionalOnClass(name = "org.apache.catalina.startup.Tomcat")
Antwort & Erklärung

Richtige Antwort: D

@ConditionalOnClass prüft die Anwesenheit angegebener Klassen im Classpath, ohne die Klasse in die Configuration-Klasse selbst laden zu müssen. Auto-Configuration-Module nutzen es stark, um Servlet-, Tomcat- oder bibliotheksspezifische Config zu aktivieren.

Warum die anderen Optionen falsch sind:

  • A) @ConditionalOnBean prüft bestehende Beans, nicht bloße Classpath-Anwesenheit.
  • B) @ConditionalOnWebApplication prüft App-Typ, nicht eine spezifische Tomcat-Klasse.
  • C) Profile sind orthogonal zu Classpath-Bedingungen.

Merksatz: „@ConditionalOnClass gated Auto-Config sicher nach Classpath-Anwesenheit."

Weiterlernen: Buchkapitel

Frage 29​

Ein Browser-Formular-POST und ein Mobile-JSON-Client treffen denselben Endpoint. Das Team will, dass eine Controller-Methode Binding passend handhabt.

Welche Komponente ist in Spring MVC der Front Controller, der alle HTTP-Requests empfängt und an Handler Mappings und Controller delegiert?


Client -> DispatcherServlet -> HandlerMapping -> Controller
  • A) HttpServletRequestWrapper
  • B) BeanFactory
  • C) DispatcherServlet
  • D) Nur HandlerInterceptor
Antwort & Erklärung

Richtige Antwort: C

DispatcherServlet ist der Spring-MVC-Front-Controller. Er routet Requests über HandlerMapping, HandlerAdapter, Controller-Aufruf, View Resolution oder Message Conversion und Exception Handling.

Warum die anderen Optionen falsch sind:

  • A) RequestWrapper ist Servlet-API-Dekoration, nicht der MVC-Front-Controller.
  • B) BeanFactory ist der IoC-Kern-Container, nicht der Web-Dispatcher.
  • D) HandlerInterceptor nimmt an der Chain teil, ersetzt aber nicht DispatcherServlet.

Merksatz: „DispatcherServlet ist der Spring-MVC-Front-Controller-Einstiegspunkt."

Weiterlernen: Buchkapitel

Frage 30​

Welche Annotation auf einer Controller-Methode mappt HTTP-GET-Requests auf /api/orders/\{id\} und bindet die Path-Variable id?


@GetMapping("/api/orders/{id}")
public OrderDto get(@PathVariable Long id) { return orderService.find(id); }
  • A) @RequestParam("id") auf der Methode
  • B) @PostMapping("/api/orders")
  • C) @GetMapping mit @PathVariable für {id}
  • D) Nur @ResponseStatus ohne Mapping
Antwort & Erklärung

Richtige Antwort: C

@GetMapping auf /api/orders/\{id\} kombiniert mit @PathVariable extrahiert die URI-Template-Variable. Das ist das Standard-REST-Muster für Ressourcenabruf per Identifier.

Warum die anderen Optionen falsch sind:

  • A) @RequestParam liest Query-Parameter, keine URI-Pfadsegmente.
  • B) POST ist die falsche HTTP-Methode für idempotenten Abruf per id.
  • D) @ResponseStatus setzt Statuscodes, definiert aber nicht die Route.

Merksatz: „Path Variables nutzen {name} im Mapping plus @PathVariable."

Weiterlernen: Buchkapitel

Frage 31​

Ein POST-Endpoint akzeptiert JSON, Clients senden manchmal XML. Das Team will JSON als Default ohne Custom Parser.

Wie serialisiert und deserialisiert Spring MVC typischerweise Request/Response-Bodies in @RestController-Methoden?

  • A) Über HttpMessageConverter-Implementierungen, ausgewählt nach Content Type und Rückgabetyp
  • B) Durch direktes Schreiben auf ServletOutputStream in jedem Controller
  • C) Über JDBC ResultSet Mapping
  • D) Nur über JSP-View-Rendering
Antwort & Erklärung

Richtige Antwort: A

RequestResponseBodyMethodProcessor nutzt HttpMessageConverter-Beans wie MappingJackson2HttpMessageConverter, um Bodies in Objekte und zurück zu konvertieren — basierend auf Content-Type, Accept und Methodensignaturen mit @RequestBody- und @ResponseBody-Semantik.

Warum die anderen Optionen falsch sind:

  • B) Controller bleiben normalerweise deklarativ; Converter übernehmen IO.
  • C) JDBC ist Persistence-Layer, nicht MVC-Body-Konvertierung.
  • D) JSP Views sind für View Resolution, nicht typische @RestController-JSON-APIs.

Merksatz: „HttpMessageConverters binden Request/Response-Bodies in Spring MVC."

Weiterlernen: Buchkapitel

Frage 32​

Was bewirkt @RestController auf einer Klasse im Vergleich zu @Controller?

  • A) Es kombiniert @Controller und @ResponseBody und schreibt Rückgabewerte über Message Converter
  • B) Es deaktiviert DispatcherServlet für diese Klasse
  • C) Es erzwingt, dass alle Methoden nur ModelAndView zurückgeben
  • D) Es fügt automatisch Spring-Security-Filter hinzu
Antwort & Erklärung

Richtige Antwort: A

@RestController ist eine zusammengesetzte Annotation, äquivalent zu @Controller plus @ResponseBody auf Klassenebene — Methoden-Rückgabewerte werden in den HTTP-Response-Body serialisiert statt als View-Namen aufgelöst.

Warum die anderen Optionen falsch sind:

  • B) DispatcherServlet dispatcht weiterhin zum Controller.
  • C) ModelAndView ist das Gegenteil des typischen REST-JSON-Rückgabestils.
  • D) Security wird separat konfiguriert, nicht durch @RestController.

Merksatz: „@RestController = @Controller + @ResponseBody."

Weiterlernen: Buchkapitel

Frage 33​

Ein Client sendet POST /api/users mit fehlender E-Mail. Die API soll 400 mit Validierungsdetails zurückgeben.

Welches Setup aktiviert automatische Validierung von Request-Body-Feldern mit Jakarta-Bean-Validation-Constraints?


public record CreateUserRequest(
    @NotBlank String name,
    @Email String email
) {}
  • A) @Valid oder @Validated auf dem @RequestBody-Parameter plus Constraints am DTO
  • B) @Transactional auf der Controller-Methode
  • C) @EnableScheduling auf der Application-Klasse
  • D) Nur @CrossOrigin auf dem Controller
Antwort & Erklärung

Richtige Antwort: A

Spring MVC triggert Bean Validation, wenn @Valid oder @Validated am @RequestBody-Argument steht und das Objekt Constraint-Annotationen enthält. Fehler werden zu MethodArgumentNotValidException, die von Exception Handlern oder Default-Problem-Responses behandelt wird.

Warum die anderen Optionen falsch sind:

  • B) Transaktionen führen keine MVC-Request-Validierung durch.
  • C) Scheduling ist unabhängig von Validierung.
  • D) CORS steuert Cross-Origin-Zugriff, nicht Validierung.

Merksatz: „@Valid auf @RequestBody aktiviert Bean Validation am DTO."

Weiterlernen: Buchkapitel

Frage 34​

Eine Controller-Advice-Klasse soll Validierungsfehler global behandeln und eine konsistente JSON-Fehlerstruktur zurückgeben. Welche Annotation passt auf diese Klasse?

  • A) @RepositoryAdvice
  • B) @ControllerAdvice
  • C) @ConfigurationProperties
  • D) @ImportResource
Antwort & Erklärung

Richtige Antwort: B

@ControllerAdvice ist eine Spezialisierung von @Component, die @ExceptionHandler-, @InitBinder- und @ModelAttribute-Methoden controller-übergreifend anwendbar macht. Das ist der Standardmechanismus für globales MVC-Exception Handling.

Warum die anderen Optionen falsch sind:

  • A) @RepositoryAdvice ist keine Standard-Spring-MVC-Annotation.
  • C) @ConfigurationProperties bindet Config-Werte.
  • D) @ImportResource lädt XML-Bean-Definitionen.

Merksatz: „Globales MVC-Exception Handling gehört in @ControllerAdvice."

Weiterlernen: Buchkapitel

Frage 35​

Eine API muss 201 Created mit Location-Header auf die neue Ressource zurückgeben.

Welche Kombination drückt HTTP-201-Semantik für eine erzeugte Ressource in Spring MVC am besten aus?

  • A) @ResponseStatus(HttpStatus.CREATED) und ResponseEntity mit Location-Header
  • B) @GetMapping und immer Status 200
  • C) @Deprecated auf der Controller-Klasse
  • D) Manuelles Thread-Sleep dann 500-Response
Antwort & Erklärung

Richtige Antwort: A

ResponseEntity oder @ResponseStatus(HttpStatus.CREATED) kommuniziert 201. ResponseEntity ist ideal, wenn du Location und Body-Header für REST-Create-Operationen explizit setzt.

Warum die anderen Optionen falsch sind:

  • B) GET mit 200 ist falsch für Ressourcenerstellung.
  • C) @Deprecated hat keine HTTP-Semantik.
  • D) Künstliche Verzögerung und Server Error sind falsches Verhalten.

Merksatz: „201 CREATED und Location-Header nutzen, wenn Ressourcen erzeugt werden."

Weiterlernen: Buchkapitel

Frage 36​

Was macht @RequestParam(defaultValue = "10"), wenn der Query-Parameter page fehlt?

  • A) Wirft sofort MissingServletRequestParameterException
  • B) Bindet page an den String-Wert 10 für den Methodenparameter
  • C) Leitet den Client auf /error um
  • D) Ignoriert den Parameter und lässt ihn für int-Primitive null
Antwort & Erklärung

Richtige Antwort: B

defaultValue liefert einen Fallback, wenn der Request-Parameter fehlt. Bei String-Parametern funktioniert das direkt; bei optionalen Typen verhindert es Absence-Errors und behält explizite Werte bei, wenn gesetzt.

Warum die anderen Optionen falsch sind:

  • A) Missing-Parameter-Exceptions entstehen bei required=true ohne Default.
  • C) Es gibt keinen automatischen Redirect.
  • D) Primitive int können nicht null sein; defaultValue vermeidet Absence-Probleme.

Merksatz: „@RequestParam defaultValue greift, wenn der Query-Parameter fehlt."

Weiterlernen: Buchkapitel

Frage 37​

Die Service-Schicht nutzt Spring-Data-JPA-Repositories. Entwickler sind unsicher, wo Transaktionsgrenzen liegen sollten.

Wo sollten @Transactional-Grenzen in einer geschichteten Spring-Anwendung mit JPA am häufigsten platziert werden?


@Service
public class OrderService {
    @Transactional
    public void placeOrder(OrderRequest request) {
        orderRepository.save(toEntity(request));
    }
}
  • A) Auf jeder Entity-Getter-Methode
  • B) Immer nur auf REST-Controller-Methoden
  • C) Auf Service-Methoden, die Repository-Operationen und Geschäftsregeln koordinieren
  • D) Nur in der main-Methode
Antwort & Erklärung

Richtige Antwort: C

Transaktionsgrenzen gehören in die Service-Schicht, wo Geschäftsoperationen mehrere Repository-Aufrufe koordinieren und Atomarität sicherstellen. Controller sollten dünn bleiben; Entities sollten keine Transaktionsabgrenzung besitzen.

Warum die anderen Optionen falsch sind:

  • A) Entity-Methoden sind Persistence-Model-Details, keine Transaktions-Orchestrierungspunkte.
  • B) Controller können in seltenen Fällen transaktional sein, aber das ist nicht das primäre Design.
  • D) main liegt außerhalb des Request/Service-Transaktionsmodells.

Merksatz: „@Transactional auf Service-Methoden setzen, die Datenänderungen orchestrieren."

Weiterlernen: Buchkapitel

Frage 38​

Was leitet Spring Data JPA aus einer Methode namens findByEmailAndActiveTrue ab?


public interface UserRepository extends JpaRepository<User, Long> {
    List<User> findByEmailAndActiveTrue(String email);
}
  • A) Einen Stored-Procedure-Aufruf namens sp_findByEmailAndActiveTrue
  • B) Automatisch ein natives SQL-Skript in schema.sql
  • C) Eine Query, die Entities selektiert, wo email dem Parameter entspricht und active true ist
  • D) Nichts; Methodennamen werden von Spring Data ignoriert
Antwort & Erklärung

Richtige Antwort: C

Spring Data JPA parst Methodennamen gegen Domain-Model-Property-Pfade und generiert Queries. findByEmailAndActiveTrue mappt auf WHERE email = ?1 AND active = true für die vom Repository verwaltete Entity.

Warum die anderen Optionen falsch sind:

  • A) Procedure-Ausführung braucht @Procedure und explizite Konfiguration.
  • B) schema.sql initialisiert Schema; es definiert keine Derived-Query-Methoden.
  • D) Derived Query Methods sind ein Kernfeature von Spring Data.

Merksatz: „Derived Query Methodennamen kodieren Property-Bedingungen nach By."

Weiterlernen: Buchkapitel

Frage 39​

Ein read-only Report-Endpoint ruft einen Service auf, der Repositories abfragt. Das Team will versehentliches Flushen dirty Entities und Optimierung von Read-Pfaden vermeiden.

Welches @Transactional-Attribut passt für eine read-only Query-Service-Methode?

  • A) readOnly = true
  • B) propagation = REQUIRES_NEW immer für Reads
  • C) rollbackFor = Exception bei jedem Read
  • D) Nur timeout = -1
Antwort & Erklärung

Richtige Antwort: A

readOnly=true signalisiert, dass die Transaktion nur lesend ist — das ermöglicht Optimierungen und reduziert unbeabsichtigte Zustandsänderungen bei manchen Providern. Das ist die Standardwahl für reine Query-Service-Methoden.

Warum die anderen Optionen falsch sind:

  • B) REQUIRES_NEW erzeugt eine neue Transaktion; das ist nicht die Default-Read-Optimierung.
  • C) rollbackFor konfiguriert Write-Failure-Verhalten, nicht Read-Semantik.
  • D) timeout allein markiert eine Transaktion nicht als read-only.

Merksatz: „@Transactional(readOnly = true) für reine Query-Service-Methoden nutzen."

Weiterlernen: Buchkapitel

Frage 40​

Eine mit @Transactional annotierte Methode ruft eine andere @Transactional-Methode in derselben Klasse auf. Was passiert mit Transaction Advice beim internen Aufruf?


@Service
public class TransferService {
    @Transactional
    public void transfer() {
        debit();
        credit();
    }

    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void debit() { accountRepository.debit(); }
}
  • A) REQUIRES_NEW startet immer eine neue Transaktion, weil die Annotation gesetzt ist
  • B) Spring-AOP-Proxy wird bei Self-Invocation umgangen, debit läuft ohne erwartete neue Transaktionsgrenze
  • C) Beide Methoden laufen automatisch ohne Transaktion
  • D) Spring wandelt den Aufruf in eine JMS-Nachricht um
Antwort & Erklärung

Richtige Antwort: B

@Transactional wird über Spring-AOP-Proxies angewendet. Ein direkter this.debit()-Aufruf im selben Target-Objekt umgeht den Proxy, sodass verschachtelte Transaktionseinstellungen wie REQUIRES_NEW nicht greifen — außer du refactorst zum Proxy-Aufruf oder injizierst ein Self-Interface.

Warum die anderen Optionen falsch sind:

  • A) Annotation allein reicht ohne Proxy-Interception nicht.
  • C) Der externe transfer-Aufruf kann weiterhin transaktional über den Proxy sein.
  • D) Transaktionsabgrenzung hat nichts mit Messaging-Konvertierung zu tun.

Merksatz: „Self-Invocation überspringt den Proxy — @Transactional greift intern oft nicht."

Weiterlernen: Buchkapitel

Frage 41​

Welche JPA-Annotation markiert ein Feld als Primärschlüssel mit datenbankgenerierten Werten in den meisten relationalen Datenbanken?

  • A) Nur @Column(unique = true)
  • B) @GeneratedValue mit @Id
  • C) @Transient
  • D) Nur @Embeddable
Antwort & Erklärung

Richtige Antwort: B

@Id bezeichnet den Primärschlüssel und @GeneratedValue konfiguriert Identity-, Sequence- oder Table-Generation-Strategien. Zusammen definieren sie Surrogate Keys, wie sie in Spring-Data-JPA-Entities üblich sind.

Warum die anderen Optionen falsch sind:

  • A) Unique-Column-Constraint definiert keine Primärschlüssel-Generierung.
  • C) @Transient schließt ein Feld von Persistence aus.
  • D) @Embeddable komponiert Value Types, nicht Primärschlüssel-Identität allein.

Merksatz: „@Id plus @GeneratedValue definiert einen auto-generierten Primärschlüssel."

Weiterlernen: Buchkapitel

Frage 42​

Eine Order-Entity hat eine lazy @OneToMany-Collection. Ein REST-Controller gibt die Order-Entity direkt zurück und Clients sehen LazyInitializationException.

Was ist die Ursache und eine saubere architektonische Lösung?

  • A) Jackson kann keine Integer serialisieren; auf XML wechseln
  • B) Lazy Collection wurde außerhalb eines offenen Persistence Contexts zugegriffen; in transaktionalem Read auf DTO mappen oder wo passend Fetch Join nutzen
  • C) @Entity-Annotation von Order entfernen
  • D) Alle Transaktionen global deaktivieren
Antwort & Erklärung

Richtige Antwort: B

Lazy Associations laden nur innerhalb einer Session. Entity-Graphen in der Web-Schicht zu serialisieren passiert oft nach Transaktionsende und triggert LazyInitializationException. DTO-Projektion oder Fetch-Strategie innerhalb der Service-Transaktion behebt das Grenzproblem.

Warum die anderen Optionen falsch sind:

  • A) Der Fehler ist Lazy-Loading-Timing, nicht Integer-Serialisierung.
  • C) @Entity entfernen bricht Persistence Mapping komplett.
  • D) Transaktionen werden gebraucht; das Problem ist Session-Grenze und API-Design.

Merksatz: „Lazy-JPA-Graphen nicht in der Web-Schicht exponieren; DTOs oder Fetch innerhalb der Transaktion."

Weiterlernen: Buchkapitel

Frage 43​

Was ist die Default-Transaktions-Propagation, wenn @Transactional kein propagation-Attribut hat?


@Transactional // propagation = Propagation.REQUIRED by default
public void updateAccount() { accountRepository.save(changes); }
  • A) REQUIRED
  • B) NOT_SUPPORTED
  • C) NEVER
  • D) MANDATORY
Antwort & Erklärung

Richtige Antwort: A

Propagation REQUIRED joint eine bestehende Transaktion oder erzeugt eine neue, wenn keine existiert. Das ist der Default und das Verhalten, das du siehst, außer du wählst explizit REQUIRES_NEW, SUPPORTS oder andere Modi.

Warum die anderen Optionen falsch sind:

  • B) NOT_SUPPORTED suspendiert Transaktionen; nicht der Default.
  • C) NEVER verbietet transaktionalen Context; nicht Default.
  • D) MANDATORY verlangt bestehende Transaktion; nicht Default.

Merksatz: „Default-Propagation ist REQUIRED: joinen oder erzeugen."

Weiterlernen: Buchkapitel

Frage 44​

Ein Bulk-Update löscht inaktive User mit einem einzelnen JPQL-Statement. Repository-Nutzer erwarten automatische Persistence-Context-Synchronisation.

Welches Spring-Data-JPA-Feature führt ein JPQL-UPDATE/DELETE-Statement aus, ohne Entities in den Speicher zu laden?

  • A) @Modifying Query Method mit @Query JPQL update/delete
  • B) Nur findAll dann delete in einer for-Schleife
  • C) @EntityGraph auf einer Finder-Methode
  • D) Nur @Version-Feld
Antwort & Erklärung

Richtige Antwort: A

@Modifying auf einer @Query-Methode führt Bulk-UPDATE oder -DELETE JPQL/SQL direkt aus. Entwickler müssen auch clearAutomatically und Transaktionsgrenzen bedenken, weil der Persistence Context nach Bulk-Operationen veraltet sein kann.

Warum die anderen Optionen falsch sind:

  • B) Jedes Entity laden nur zum Einzel-Löschen verfehlt den Zweck von Bulk-Operationen und skaliert schlecht.
  • C) Entity Graphs steuern Fetch Graphs für Queries, nicht Bulk-Update/Delete-Ausführung.
  • D) @Version ermöglicht Optimistic Locking auf Entities, führt aber keine Bulk-JPQL-Statements aus.

Merksatz: „@Modifying @Query führt Bulk-Updates/Deletes ohne Entity-für-Entity-Laden aus."

Weiterlernen: Buchkapitel

Frage 45​

Eine stateless REST-API muss Bearer-Tokens bei jedem Request authentifizieren ohne serverseitige HTTP-Sessions.

Welche Spring-Security-Konfigurationsrichtung passt am besten zu einer stateless JWT-gestützten API?


http.sessionManagement(s -> s.sessionCreationPolicy(STATELESS));
http.addFilterBefore(jwtAuthFilter, UsernamePasswordAuthenticationFilter.class);
  • A) formLogin mit Default-Success-URL /home
  • B) rememberMe immer aktiviert mit persistenten Tokens in JDBC
  • C) sessionManagement sessionCreationPolicy STATELESS plus Filter, der Tokens vor UsernamePasswordAuthenticationFilter validiert
  • D) CSRF aktiviert mit HttpSession-Pflicht für jeden Request
Antwort & Erklärung

Richtige Antwort: C

Stateless APIs deaktivieren Session-Erzeugung für Auth-State und verlassen sich auf per-Request-Token-Validierung in der Security-Filter-Chain. Ein Custom OncePerRequestFilter oder Resource-Server-Support validiert Credentials und befüllt den SecurityContext pro Request.

Warum die anderen Optionen falsch sind:

  • A) Form Login ist browser-session-orientiert, nicht typisch für Bearer-Token-APIs.
  • B) Remember-me zentriert weiterhin Session/Cookie-Muster, unpassend für reine stateless JWT-APIs.
  • D) CSRF-Schutz ist wichtig für Cookie-Sessions; stateless Bearer-Setups deaktivieren CSRF oft für reine APIs, schützen aber weiterhin session-basierte Apps.

Merksatz: „Stateless APIs nutzen STATELESS Sessions und per-Request-Token-Authentication-Filter."

Weiterlernen: Buchkapitel

Frage 46​

In der Spring-Security-Filter-Chain-Architektur: Wo wird der SecurityContext typischerweise für einen Request gespeichert?


Authentication auth = SecurityContextHolder.getContext().getAuthentication();
  • A) Nur in der Datenbank-User-Tabelle
  • B) Dauerhaft im JPA EntityManager
  • C) In application.properties
  • D) In SecurityContextHolder, oft mit ThreadLocal für Servlet-Requests
Antwort & Erklärung

Richtige Antwort: D

SecurityContextHolder hält Principal und Authorities für den aktuellen Thread während der Request-Verarbeitung. Servlet-Filter befüllen und leeren ihn um die Chain, um Credential-Leaks zwischen Requests zu vermeiden.

Warum die anderen Optionen falsch sind:

  • A) User-Tabellen speichern Credentials oder Accounts, nicht per-Request-Context.
  • B) EntityManager ist Persistence-Infrastruktur, nicht Security-Context-Speicher.
  • C) Properties-Dateien halten keinen Runtime-Authentication-State.

Merksatz: „SecurityContextHolder trägt Authentication für den aktuellen Request-Thread."

Weiterlernen: Buchkapitel

Frage 47​

Administratoren brauchen /admin/-Endpoints auf ROLE_ADMIN beschränkt, während andere authentifizierte User /app/ nutzen dürfen.

Welcher Ausdruck auf einer authorizeHttpRequests-Regel gewährt Zugriff nur für User mit ROLE_ADMIN?

  • A) permitAll() für /admin/**
  • B) hasRole("ADMIN") für /admin/**-Requests
  • C) anonymous() für /admin/**
  • D) Nur csrf().disable()
Antwort & Erklärung

Richtige Antwort: B

hasRole("ADMIN") prüft auf ROLE_ADMIN-Authority nach Spring-Security-Rollen-Namenskonvention. Methoden- und HTTP-Authorization-Regeln nutzen solche Ausdrücke für rollenbasierte Zugriffskontrolle.

Warum die anderen Optionen falsch sind:

  • A) permitAll erlaubt jeden inklusive anonymer User.
  • C) anonymous beschränkt auf nicht authentifizierte User — Gegenteil von admin-only.
  • D) CSRF-Einstellungen definieren keine Authorization-Rollen.

Merksatz: „hasRole("ADMIN") mappt auf Authority ROLE_ADMIN."

Weiterlernen: Buchkapitel

Frage 48​

Was macht PasswordEncoder in der Spring-Security-Authentication-Architektur?

  • A) Mappt URLs auf Controller-Methoden
  • B) Hasht und verifiziert Passwörter ohne Klartext-Speicherung
  • C) Generiert automatisch JWT-Signing-Keys für alle Apps
  • D) Ersetzt die Notwendigkeit von HTTPS
Antwort & Erklärung

Richtige Antwort: B

PasswordEncoder bietet One-Way-Encoding und matched Raw-Passwörter gegen gespeicherte Hashes bei der Authentifizierung. DelegatingPasswordEncoder unterstützt mehrere Algorithmen und ist der empfohlene Ansatz in modernem Spring Security.

Warum die anderen Optionen falsch sind:

  • A) URL-Mapping ist MVC-Belang.
  • C) JWT-Keys werden separat konfiguriert; PasswordEncoder handhabt Passwort-Hashing.
  • D) Transport-Sicherheit braucht weiterhin TLS.

Merksatz: „Nie Klartext-Passwörter speichern; mit PasswordEncoder.matches verifizieren."

Weiterlernen: Buchkapitel

Frage 49​

Eine browserbasierte App nutzt Cookie-Sessions und Form Login. Entwickler exponieren einen REST-POST-Endpoint, den dieselbe Origin konsumiert.

Warum ist CSRF-Schutz in dieser Anwendung relevant?

  • A) Weil Browser Session-Cookies bei Cross-Site-Requests automatisch senden können und gefälschte state-changing Operationen ermöglichen, außer CSRF-Tokens werden validiert
  • B) Weil JWT-Signaturen standardmäßig nach einer Sekunde ablaufen
  • C) Weil @Transactional CSRF-Tokens braucht
  • D) Weil CSRF Passwort-Hashing ersetzt
Antwort & Erklärung

Richtige Antwort: A

Session-Cookie-Authentifizierung ist anfällig für Cross-Site Request Forgery, wenn Browser Cookies automatisch anhängen. Spring-Security-CSRF-Tokens verifizieren beabsichtigte Client-Requests für state-changing Operationen in session-basierten Apps.

Warum die anderen Optionen falsch sind:

  • B) JWT-Ablauf ist unabhängig von CSRF für Cookie-Session-Apps.
  • C) Transaktionen sind Persistence-Belang.
  • D) CSRF ersetzt keine Credential-Storage-Schutzmaßnahmen.

Merksatz: „Cookie-Session-Apps brauchen CSRF-Schutz bei state-changing Requests."

Weiterlernen: Buchkapitel

Frage 50​

Welche Annotation aktiviert Method-Level-Security-Ausdrücke wie @PreAuthorize("hasAuthority('INVOICE_READ')")?

  • A) @EnableMethodSecurity
  • B) @EnableWebMvc
  • C) @EnableJpaRepositories
  • D) @EnableScheduling
Antwort & Erklärung

Richtige Antwort: A

@EnableMethodSecurity aktiviert Method-Interception für @PreAuthorize, @PostAuthorize, @Secured und verwandte Annotationen über Spring AOP um gesicherte Beans.

Warum die anderen Optionen falsch sind:

  • B) @EnableWebMvc konfiguriert MVC-Infrastruktur, nicht Authorization auf Service-Methoden.
  • C) @EnableJpaRepositories scannt nur Repository-Interfaces.
  • D) @EnableScheduling aktiviert Scheduled-Task-Ausführung, unabhängig von Method Security.

Merksatz: „@EnableMethodSecurity schaltet @PreAuthorize und verwandte Checks ein."

Weiterlernen: Buchkapitel

Frage 51​

Unit-Tests für OrderService sollen Geschäftslogik von Datenbank- und HTTP-Belangen isolieren.

Was ist das Hauptziel eines Spring-Service-Unit-Tests mit Mockito?

  • A) Vollen Servlet-Container booten und echte Endpoints treffen
  • B) Die Service-Klasse isoliert testen, indem Collaborators mit @ExtendWith(MockitoExtension.class) oder @Mock/@InjectMocks gemockt werden
  • C) @SpringBootTest für jeden Service-Test verlangen
  • D) Produktions-PostgreSQL für jede Testmethode laden
Antwort & Erklärung

Richtige Antwort: B

Unit-Tests fokussieren Verhalten einer Klasse, indem Abhängigkeiten durch Mocks ersetzt werden. Mockito integriert mit JUnit 5, um Interaktionen zu verifizieren und kontrollierte Antworten ohne Spring-Start zu liefern, wenn nicht nötig.

Warum die anderen Optionen falsch sind:

  • A) Full-Container-Tests sind Integrationstests, keine Unit-Tests.
  • C) @SpringBootTest ist schwerer als nötig für reine Unit-Tests.
  • D) Produktionsdatenbanken machen Tests langsam und brüchig.

Merksatz: „Services mit Mocks unit-testen; Spring Context für Integrationstests reservieren."

Weiterlernen: Buchkapitel

Frage 52​

Welche Annotation startet den vollen Spring-Application-Context inklusive Auto-Configuration für einen Integrationstest?

  • A) @WebMvcTest
  • B) @DataJpaTest
  • C) Nur @MockBean ohne Context
  • D) @SpringBootTest
Antwort & Erklärung

Richtige Antwort: D

@SpringBootTest lädt den kompletten Application Context (oder einen konfigurierten Slice über Attribute) und wird für Integrationstests genutzt, die echte Verdrahtung über Schichten brauchen — oft mit TestRestTemplate oder @Autowired-Collaborators.

Warum die anderen Optionen falsch sind:

  • A) @WebMvcTest lädt nur MVC-Slice.
  • B) @DataJpaTest lädt JPA-Slice typischerweise mit In-Memory-DB.
  • C) @MockBean braucht einen Spring-Test-Context; es bootstrapped nicht allein.

Merksatz: „@SpringBootTest = vollständiger Integration-Context-Bootstrap."

Weiterlernen: Buchkapitel

Frage 53​

Ein Controller-Test soll JSON-Response-Status und Body verifizieren, ohne einen echten Server auf zufälligem Port zu starten.

Welcher Test-Slice passt zum Testen eines @RestController mit MockMvc?

  • A) @WebMvcTest(controllers = InvoiceController.class)
  • B) Nur @SpringBootTest webEnvironment RANDOM_PORT
  • C) @JdbcTest
  • D) Nur @JsonTest für den gesamten MVC-Flow
Antwort & Erklärung

Richtige Antwort: A

@WebMvcTest konfiguriert Spring-MVC-Infrastruktur und MockMvc, begrenzt den Context auf Web-Layer-Beans und lässt dich Controller-Mappings, Statuscodes und JSON mit leichtem Setup testen.

Warum die anderen Optionen falsch sind:

  • B) RANDOM_PORT funktioniert, ist aber schwerer als nötig für Controller-Slice-Tests.
  • C) @JdbcTest zielt nur auf JDBC-Komponenten.
  • D) @JsonTest fokussiert JSON-Serializer, nicht vollständiges Controller-Request-Mapping.

Merksatz: „@WebMvcTest plus MockMvc testet Controller ohne vollen Boot-Startup."

Weiterlernen: Buchkapitel

Frage 54​

In einem @WebMvcTest muss eine Service-Abhängigkeit durch eine Mock-Implementierung ersetzt werden. Welche Annotation registriert den Mock im Test-Context?

  • A) @MockBean
  • B) Nur @Mock ohne Spring Context
  • C) @Entity
  • D) @Profile
Antwort & Erklärung

Richtige Antwort: A

@MockBean sagt Spring Test, einen Mockito-Mock als Bean im Application Context hinzuzufügen — bestehende Beans zu ersetzen oder zu ergänzen. Das ist nötig, wenn der getestete Controller Collaborators während @WebMvcTest autowiret.

Warum die anderen Optionen falsch sind:

  • B) @Mock allein registriert keinen Bean im Spring-Test-ApplicationContext.
  • C) @Entity ist eine JPA-Mapping-Annotation, kein Test-Mock-Registrierungsmechanismus.
  • D) @Profile wählt Beans nach Umgebung; es erzeugt keine Mock-Implementierungen.

Merksatz: „@MockBean nutzen, um Mockito-Mocks in Spring-Test-Contexts zu injizieren."

Weiterlernen: Buchkapitel

Frage 55​

Repository-Integrationstests sollen gegen eine In-Memory-Datenbank laufen mit nur geladenen JPA-Komponenten.

Welche Spring-Boot-Test-Annotation ist für JPA-Repository-Slice-Tests gedacht?

  • A) @DataJpaTest
  • B) @WebMvcTest
  • C) Nur @SpringBootConfiguration
  • D) @ControllerAdvice
Antwort & Erklärung

Richtige Antwort: A

@DataJpaTest konfiguriert JPA-bezogene Beans, typischerweise mit Embedded Database, und ist ideal zum Testen von Repository-Query-Methoden ohne die gesamte Anwendung zu laden.

Warum die anderen Optionen falsch sind:

  • B) @WebMvcTest begrenzt den Context auf die Web-Schicht, nicht Repositories.
  • C) @SpringBootConfiguration markiert eine Config-Klasse, definiert aber keinen Repository-Test-Slice.
  • D) @ControllerAdvice ist für MVC-Exception Handling, nicht Repository-Integrationstests.

Merksatz: „@DataJpaTest lädt einen minimalen JPA-Test-Slice mit Embedded DB."

Weiterlernen: Buchkapitel

Frage 56​

Was macht @Transactional auf einer Spring-Boot-Integrationstest-Methode typischerweise mit Datenbankänderungen während des Tests?

  • A) Committet sie dauerhaft ins Produktionsschema
  • B) Rollt nach dem Test standardmäßig zurück und hält Tests isoliert
  • C) Deaktiviert die Datenbank komplett
  • D) Führt den Test ohne DataSource aus
Antwort & Erklärung

Richtige Antwort: B

Spring-Test-Framework-Transaktionsunterstützung rollt Transaktionen nach jeder Testmethode standardmäßig zurück — das verhindert Testdaten-Verschmutzung und übt trotzdem echte transaktionale Codepfade.

Warum die anderen Optionen falsch sind:

  • A) Default-Test-Transaktionen rollen zurück, nicht ins Produktionsschema committen.
  • C) Der DataSource bleibt aktiv; transaktionale Tests nutzen ihn innerhalb einer zurückgerollten Transaktion.
  • D) Integrationstests mit @Transactional brauchen weiterhin einen konfigurierten DataSource.

Merksatz: „Test-@Transactional-Methoden rollen standardmäßig für Isolation zurück."

Weiterlernen: Buchkapitel

Frage 57​

Ein Logging-Aspect soll vor jeder public Methode im Service-Package laufen — aber nur auf Spring Beans.

Warum muss der Ziel-Service ein Spring-verwalteter Bean sein, damit Spring-AOP-Advice greift?

  • A) Weil Advice über Proxies oder Subclass Weaving um vom Container erzeugte Beans angewendet wird
  • B) Weil Java keine Methoden auf Klassen unterstützt
  • C) Weil nur @Entity-Klassen geproxyt werden können
  • D) Weil Aspects in application.properties kompiliert werden
Antwort & Erklärung

Richtige Antwort: A

Spring AOP wrappt Beans mit JDK-Dynamic-Proxies oder CGLIB-Subclasses, sodass Interceptors um Join Points laufen können. Mit new außerhalb des Containers erzeugte Objekte werden nicht geproxyt und umgehen daher Advice.

Warum die anderen Optionen falsch sind:

  • B) Plain-Java-Methoden existieren; das Problem ist Proxy-Registrierung.
  • C) Entities sind unabhängig von AOP-Proxy-Anforderungen.
  • D) Aspects sind Beans/Advice-Definitionen, keine Property-Dateien.

Merksatz: „Spring AOP gilt für container-verwaltete Beans über Proxies."

Weiterlernen: Buchkapitel

Frage 58​

SRE braucht einen Custom Counter für fehlgeschlagene Payment-Versuche über Actuator, kompatibel mit Prometheus-Scraping.

Welcher Spring-Boot-Ansatz registriert eine Custom Application Metric, die von Micrometer gesammelt und über Actuator exponiert wird?


@Service
public class PaymentService {
    private final Counter failedPayments;

    public PaymentService(MeterRegistry registry) {
        this.failedPayments = registry.counter("payments.failed");
    }
}
  • A) Counter über MeterRegistry deklarieren und in Business-Code inkrementieren
  • B) @Entity auf der Service-Klasse, damit JPA Metriken automatisch trackt
  • C) Metrikwerte nur in statischer HashMap ohne MeterRegistry speichern
  • D) management.endpoints.web.exposure deaktivieren, um Custom Metrics zu erzeugen
Antwort & Erklärung

Richtige Antwort: A

Spring-Boot-Actuator integriert Micrometer, sodass Beans Counter, Timer und Gauges über MeterRegistry registrieren können. Diese Meter erscheinen auf /actuator/metrics und können nach Prometheus exportiert werden, wenn Registry und Exporter konfiguriert sind.

Warum die anderen Optionen falsch sind:

  • B) JPA-Entity-Mapping hat keinen Bezug zu Application-Metrics-Registrierung.
  • C) Ad-hoc-statische Maps sind nicht mit Actuator-Endpoints oder standardisierten Metric Registries integriert.
  • D) Actuator-Endpoints verstecken verhindert Observability statt Custom Metrics zu ermöglichen.

Merksatz: „Custom Metrics mit MeterRegistry registrieren; Actuator exponiert sie über Micrometer."

Weiterlernen: Buchkapitel

Frage 59​

Wenn eine Bestellung aufgegeben wird, müssen mehrere Module reagieren: E-Mail senden, Inventar aktualisieren, auditieren. Der Order Service soll auf Persistenz fokussiert bleiben.

Welches Spring-Feature entkoppelt Side Effects, indem Listener benachrichtigt werden, wenn OrderCreatedEvent publiziert wird?


publisher.publishEvent(new OrderCreatedEvent(orderId));

@EventListener
void onOrderCreated(OrderCreatedEvent event) { emailService.sendReceipt(event); }
  • A) Gesamte Logik in eine riesige @Transactional-Methode mit switch-cases packen
  • B) Statischen Singleton-Event-Bus außerhalb von Spring nutzen
  • C) ApplicationEventPublisher und @EventListener-Methoden
  • D) Den ApplicationContext deaktivieren
Antwort & Erklärung

Richtige Antwort: C

Spring Application Events lassen einen Publisher Domain Events emittieren und Listener synchron oder asynchron über @EventListener reagieren. Das hält den Kern-Workflow zusammenhängend, während Erweiterbarkeit in Listenern lebt.

Warum die anderen Optionen falsch sind:

  • A) Eine monolithische Methode koppelt Side Effects eng und schadet der Wartbarkeit.
  • B) Ein statischer Bus umgeht Spring-Lifecycle und Testbarkeitsvorteile.
  • D) Context deaktivieren entfernt die Event-Infrastruktur komplett.

Merksatz: „Domain Events publizieren; Side Effects mit @EventListener behandeln."

Weiterlernen: Buchkapitel

Frage 60​

Welche Konfiguration aktiviert Spring-@Async-Methodenausführung mit einem Task Executor?


@Configuration
@EnableAsync
class AsyncConfig { }
  • A) Nur @EnableWebMvc
  • B) Nur @EntityScan
  • C) Nur @RefreshScope
  • D) @EnableAsync auf einer @Configuration-Klasse
Antwort & Erklärung

Richtige Antwort: D

@EnableAsync aktiviert die Verarbeitung von @Async-Methoden über Spring AOP und TaskExecutor-Infrastruktur. Ohne es laufen @Async-Methoden synchron auf dem Caller-Thread.

Warum die anderen Optionen falsch sind:

  • A) @EnableWebMvc konfiguriert Web MVC, nicht asynchrone Methodenausführung.
  • B) @EntityScan begrenzt JPA-Entity-Scanning auf angegebene Packages.
  • C) @RefreshScope ist ein Spring-Cloud-Scope für refreshed Configuration Beans.

Merksatz: „@EnableAsync schaltet asynchrone @Async-Methodenbehandlung ein."

Weiterlernen: Buchkapitel

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