Zum Hauptinhalt springen

Mock Full 05 — 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 Team registriert eine Utility-Klasse mit new im Controller, statt sie von Spring zu injizieren.

Warum nimmt das manuell erzeugte Utility nicht an Dependency Injection teil?

  • A) Nur @Repository-Klassen können injizierte Collaborators erhalten
  • B) Mit new erzeugte Objekte werden vom IoC-Container nicht verwaltet, sofern sie nicht explizit als Beans registriert sind
  • C) Der Controller-Scope verhindert die Verdrahtung von Hilfsobjekten
  • D) Spring injiziert Abhängigkeiten nur in statische Methoden
Antwort & Erklärung

Richtige Antwort: B

Spring Dependency Injection gilt für Objekte, die der Container erzeugt und verwaltet. new umgeht die Bean-Registrierung — es gibt keine Injection, keine Lifecycle-Callbacks und kein Proxying für diese Instanz.

Warum die anderen Optionen falsch sind:

  • A) Jede Stereotyp-Annotation oder @Bean kann injiziert werden, nicht nur Repositories.
  • C) Der Controller-Scope blockiert nicht die Injection in korrekt registrierte Beans.
  • D) Spring injiziert in normaler Nutzung nicht in statische Methoden.

Merksatz: „new() erzeugt Nicht-Beans; nur container-verwaltete Objekte bekommen DI."

Weiterlernen: Buchkapitel

Frage 2​

Wie hängen Inversion of Control (IoC) und Dependency Injection (DI) zusammen?

  • A) DI ersetzt IoC in modernem Spring vollständig
  • B) IoC ist das Prinzip; DI ist eine gängige Technik zur Umsetzung von IoC
  • C) IoC gilt nur für Webanwendungen; DI nur für Batch-Jobs
  • D) Es sind unabhängige Konzepte, die zufällig dieselben Annotationen teilen
Antwort & Erklärung

Richtige Antwort: B

IoC bedeutet, dass die Kontrolle über Objekterzeugung und Verdrahtung an einen Container umgekehrt wird. DI ist ein Weg, IoC umzusetzen, indem Abhängigkeiten von außen geliefert werden, statt dass die Klasse sie selbst konstruiert.

Warum die anderen Optionen falsch sind:

  • A) DI ersetzt IoC nicht; es setzt die IoC-Idee um.
  • C) Beide Konzepte gelten für alle Anwendungstypen.
  • D) Sie sind direkt verwandte Grundkonzepte von Spring.

Merksatz: „IoC ist die Idee; DI ist, wie Spring sie meist umsetzt."

Weiterlernen: Buchkapitel

Frage 3​

Wie viele PaymentGateway-Collaborators injiziert Spring in diesen einzigen öffentlichen Konstruktor?


@Component
public class OrderRouter {
    @Autowired
    public OrderRouter(PaymentGateway gateway) { }
}
  • A) Keine, weil @Autowired an jedem Konstruktorparameter erforderlich ist
  • B) Ein passender PaymentGateway-Bean aus dem Container
  • C) Alle PaymentGateway-Beans automatisch als List
  • D) Eine neue PaymentGateway-Instanz pro HTTP-Request unabhängig vom Scope
Antwort & Erklärung

Richtige Antwort: B

Bei einem einzigen Konstruktor behandelt Spring 4.3+ ihn als Autowiring-Konstruktor, auch ohne @Autowired. Ein kompatibler PaymentGateway-Bean wird injiziert, sofern nicht mehrere Kandidaten @Qualifier erfordern.

Warum die anderen Optionen falsch sind:

  • A) @Autowired ist bei einem einzigen Konstruktor optional.
  • C) Mehrere Beans erfordern explizite Collection-Injection oder Qualifier-Handling.
  • D) Request-Scope folgt nicht aus Konstruktor-Injection.

Merksatz: „Einzelner Konstruktor = in Spring standardmäßig autowired."

Weiterlernen: Buchkapitel

Frage 4​

Welche Stereotyp-Annotation passt am besten für eine Klasse, die Persistenz-Exceptions in die Spring-DataAccessException-Hierarchie übersetzt?

  • A) @Service
  • B) @Repository
  • C) @Controller
  • D) @Configuration
Antwort & Erklärung

Richtige Antwort: B

@Repository markiert die Persistenzschicht und aktiviert PersistenceExceptionTranslationPostProcessor zur Umwandlung von Vendor-Exceptions in Spring-Datenzugriffs-Exceptions.

Warum die anderen Optionen falsch sind:

  • A) @Service ist für Business-Logik, nicht für Persistenz-Exception-Translation.
  • C) @Controller dispatcht Web-Requests.
  • D) @Configuration definiert Bean-Factories, keine DAO-/Repository-Rolle.

Merksatz: „@Repository = Persistenzschicht plus Exception-Translation."

Weiterlernen: Buchkapitel

Frage 5​

Was fügt @RestController im Vergleich zu @Controller allein hinzu?


@RestController
public class InvoiceController { }

// vs

@Controller
public class InvoicePageController { }
  • A) @ResponseBody-Semantik auf Handler-Methoden, sodass Rückgabewerte direkt in den HTTP-Body geschrieben werden
  • B) Automatisches Transaction Management auf jedem Handler
  • C) Obligatorische CSRF-Token-Validierung auf allen Endpoints
  • D) Prototype-Scope für den Controller-Bean
Antwort & Erklärung

Richtige Antwort: A

@RestController ist eine zusammengesetzte Annotation aus @Controller und @ResponseBody — Rückgabewerte werden über HttpMessageConverters serialisiert statt über View Resolution.

Warum die anderen Optionen falsch sind:

  • B) Transaktionen werden nicht durch @RestController aktiviert.
  • C) CSRF ist ein Security-Thema, nicht Teil von @RestController.
  • D) Controller bleiben standardmäßig Singleton.

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

Weiterlernen: Buchkapitel

Frage 6​

Ein Bean ist mit Scope singleton (Standard) deklariert. Was bedeutet Singleton in Spring?

  • A) Eine Instanz pro HTTP-Session
  • B) Eine Instanz pro JVM global über alle Anwendungen
  • C) Eine gemeinsame Instanz pro Spring-IoC-Container
  • D) Eine Instanz pro Thread
Antwort & Erklärung

Richtige Antwort: C

Spring Singleton-Scope bedeutet eine Bean-Instanz pro Container — nicht global pro Class Loader oder pro Thread. Das ist der Standard für die meisten Beans.

Warum die anderen Optionen falsch sind:

  • A) Session-Scope erzeugt eine Instanz pro HTTP-Session.
  • B) Mehrere Spring-Contexts in einer JVM haben jeweils ihre eigene Singleton-Instanz.
  • D) Thread-Scope ist separat und nicht der Standard.

Merksatz: „Spring Singleton = eine Instanz pro Container."

Weiterlernen: Buchkapitel

Frage 7​

Der Startup schlägt mit NoUniqueBeanDefinitionException für DataExporter fehl, wenn zwei Implementierungen existieren.

Welche Annotation markiert einen Bean als Standard bei Autowiring nach Typ?

  • A) @Order
  • B) @Primary
  • C) @DependsOn
  • D) @Lazy
Antwort & Erklärung

Richtige Antwort: B

@Primary wählt einen bevorzugten Bean, wenn mehrere Kandidaten für einen Injection Point nach Typ passen. Andere Consumer können weiterhin @Qualifier für einen Nicht-Primary-Bean nutzen.

Warum die anderen Optionen falsch sind:

  • A) @Order beeinflusst Reihenfolge von Listen oder Advice, nicht Autowire-Präferenz.
  • C) @DependsOn steuert Initialisierungsreihenfolge.
  • D) @Lazy verzögert Erzeugung, löst aber keine Mehrdeutigkeit.

Merksatz: „Typ-Mehrdeutigkeit → @Primary auf dem bevorzugten Bean."

Weiterlernen: Buchkapitel

Frage 8​

Was bewirkt @ComponentScan auf einer @Configuration-Klasse beim Context Refresh?


@Configuration
@ComponentScan(basePackages = "com.example.billing")
public class BillingConfig { }
  • A) Nur @Bean-Methoden in BillingConfig werden verarbeitet
  • B) Classpath-Scanning registriert stereotyp-annotierte Klassen unter com.example.billing als Bean-Definitionen
  • C) Alle Klassen auf dem JVM-Classpath werden automatisch Beans
  • D) Component Scanning läuft nur im Production-Profil
Antwort & Erklärung

Richtige Antwort: B

@ComponentScan weist den Container an, die angegebenen Packages nach @Component, @Service, @Repository, @Controller und anderen Stereotypen zu scannen und sie als Beans zu registrieren.

Warum die anderen Optionen falsch sind:

  • A) @Bean-Methoden werden separat vom Scanning verarbeitet.
  • C) Nur annotierte Klassen in gescannten Packages werden registriert.
  • D) Scanning ist nicht profilgebunden, sofern nicht so konfiguriert.

Merksatz: „@ComponentScan registriert annotierte Klassen in den angegebenen Packages."

Weiterlernen: Buchkapitel

Frage 9​

BeanFactory versus ApplicationContext: Welche Fähigkeit ist typischerweise mit ApplicationContext verbunden, nicht aber mit dem minimalen BeanFactory-Vertrag?

  • A) Beans nach Name abrufen
  • B) ApplicationEvents an Listener publizieren
  • C) Singleton- versus Prototype-Scope prüfen
  • D) Bean-Referenzen nach Typ holen
Antwort & Erklärung

Richtige Antwort: B

ApplicationContext erweitert BeanFactory und fügt Event-Propagation, MessageSource, Resource-Loading-Hilfen und automatische BeanPostProcessor-Registrierung beim Refresh hinzu.

Warum die anderen Optionen falsch sind:

  • A) Bean-Abruf existiert auf BeanFactory.
  • C) Scope-Inspektion ist auf BeanFactory verfügbar.
  • D) Typbasiertes Lookup ist eine BeanFactory-Fähigkeit.

Merksatz: „ApplicationContext ergänzt Events, i18n und reichere Container-Integration."

Weiterlernen: Buchkapitel

Frage 10​

Warum wird Field Injection wie hier in Spring-Anwendungen abgeraten?


@Service
public class PricingService {
    @Autowired
    private DiscountPolicy discountPolicy;
}
  • A) Sie verhindert, dass die Klasse geproxied wird
  • B) Sie verbirgt erforderliche Abhängigkeiten, erschwert Tests und erlaubt keine einfache Unveränderlichkeit
  • C) Sie funktioniert nur mit XML-Konfiguration
  • D) Sie deaktiviert Component Scanning für die Klasse
Antwort & Erklärung

Richtige Antwort: B

Field Injection macht Abhängigkeiten weniger sichtbar, erschwert Unit-Tests ohne Reflection oder Spring und ist mit finalen unveränderlichen Feldern inkompatibel. Konstruktor-Injection ist für erforderliche Collaborators bevorzugt.

Warum die anderen Optionen falsch sind:

  • A) Proxies können field-injizierte Beans weiterhin wrappen.
  • C) Field Injection funktioniert mit Annotation Config.
  • D) Component Scanning ist unbetroffen.

Merksatz: „Konstruktor-Injection bevorzugen; Field Injection verbirgt Abhängigkeiten."

Weiterlernen: Buchkapitel

Frage 11​

Was erzeugt die @Bean-Methode im Spring-Container?


@Configuration
public class AppConfig {
    @Bean
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}
  • A) Eine statische Utility-Klasse, nur nach Name registriert
  • B) Eine Bean-Instanz, deren Lifecycle der Container verwaltet
  • C) Einen Prototype-Controller, der auf /restTemplate gemappt ist
  • D) Einen Property-Placeholder aus application.yml
Antwort & Erklärung

Richtige Antwort: B

@Bean-Methoden sind Factory-Methoden, die von Configuration-Class-Enhancement verarbeitet werden. Der Rückgabewert wird als Bean mit container-verwaltetem Lifecycle und Injection-Support registriert.

Warum die anderen Optionen falsch sind:

  • A) Der Rückgabewert ist ein verwalteter Bean, kein reiner Name-Alias.
  • C) @Bean erzeugt keine Web-Endpoints.
  • D) Property-Placeholders nutzen @Value oder @ConfigurationProperties.

Merksatz: „Rückgabewert einer @Bean-Methode wird ein Spring-verwalteter Bean."

Weiterlernen: Buchkapitel

Frage 12​

Eine @Configuration-Klasse definiert zwei @Bean-Methoden, wobei eine die andere aufruft. Warum können beide Aufrufe dieselbe Instanz zurückgeben?

  • A) @Configuration-Klassen werden enhanced, sodass @Bean-Methoden geproxied werden und Singleton-Semantik innerhalb der Klasse gilt
  • B) Die JVM cached alle Methodenrückgabewerte global
  • C) Spring nutzt immer Prototype-Scope für @Bean-Methoden
  • D) @Bean-Methoden dürfen sich nicht gegenseitig aufrufen
Antwort & Erklärung

Richtige Antwort: A

Full-@Configuration-Mode proxied @Bean-Methoden, sodass Intra-Class-Aufrufe über den Container laufen und Singleton-Beans nicht versehentlich doppelt erzeugt werden.

Warum die anderen Optionen falsch sind:

  • B) Die JVM cached nicht global beliebige Methodenrückgaben.
  • C) Standard-@Bean-Scope ist Singleton, sofern nicht anders angegeben.
  • D) @Bean-Methoden können sich aufrufen; Proxying ist das Schlüsselverhalten.

Merksatz: „@Configuration proxied @Bean-Methoden, um doppelte Singletons zu vermeiden."

Weiterlernen: Buchkapitel

Frage 13​

Wie entscheidet Spring, welcher PaymentClient-Bean aktiv ist?


@Bean
@Profile("staging")
public PaymentClient stagingClient() { return new StagingClient(); }

@Bean
@Profile("production")
public PaymentClient productionClient() { return new ProductionClient(); }
  • A) Beide Beans werden immer geladen und @Primary wählt einen
  • B) Nur der Bean, dessen @Profile zu aktiven Profilen passt, wird registriert
  • C) Profile werden für @Bean-Methoden ignoriert
  • D) Der zuletzt deklarierte @Bean gewinnt immer
Antwort & Erklärung

Richtige Antwort: B

@Profile registriert Bean-Definitionen bedingt. Nur Profile, die zu spring.profiles.active (oder Äquivalent) passen, machen den Bean im Context verfügbar.

Warum die anderen Optionen falsch sind:

  • A) Nicht passende Profil-Beans werden nicht registriert — typischerweise keine Mehrdeutigkeit.
  • C) Profile gelten vollständig für @Bean-Definitionen.
  • D) Deklarationsreihenfolge überschreibt keine Profilbedingungen.

Merksatz: „@Profile registriert Beans nur, wenn das Profil aktiv ist."

Weiterlernen: Buchkapitel

Frage 14​

Was ist der Hauptzweck von @ConfigurationProperties auf einer typsicheren Properties-Klasse?

  • A) SQL aus Property-Keys generieren
  • B) Externe Konfiguration unter einem Prefix an Java-Objektfelder binden
  • C) @ComponentScan ersetzen
  • D) Method Security auf Configuration-Klassen aktivieren
Antwort & Erklärung

Richtige Antwort: B

@ConfigurationProperties bindet Environment-Properties mit einem Prefix an Felder oder Konstruktorparameter einer Klasse — validierter, typsicherer Konfigurationszugriff.

Warum die anderen Optionen falsch sind:

  • A) Es generiert kein SQL.
  • C) Component Scanning ist unabhängig.
  • D) Security-Annotationen sind separat.

Merksatz: „@ConfigurationProperties = Prefix-Properties an eine Klasse binden."

Weiterlernen: Buchkapitel

Frage 15​

Was bedeutet die :30-Syntax in diesem @Value-Ausdruck?


@Value("${app.timeout:30}")
private int timeout;
  • A) Eine Pflicht-Property, deren Fehlen den Startup abbricht
  • B) Ein Default-Wert 30, wenn app.timeout nicht gesetzt ist
  • C) Ein automatisch aktiviertes Profil
  • D) Eine SpEL-Arithmetikoperation
Antwort & Erklärung

Richtige Antwort: B

Der Doppelpunkt in $\{property:default\} liefert einen Fallback, wenn die Property fehlt. Das ist Property-Placeholder-Auflösung, keine Profilaktivierung.

Warum die anderen Optionen falsch sind:

  • A) Pflicht-Properties ohne Default führen bei Fehlen zum Abbruch.
  • C) Profile nutzen @Profile oder spring.profiles.active.
  • D) Das ist kein SpEL, außer in #{...} gewrappt.

Merksatz: „${key:default} = Property mit Fallback-Default."

Weiterlernen: Buchkapitel

Frage 16​

Ein Singleton-Service injiziert einen Prototype-Formatter-Bean direkt. Was passiert?

  • A) Bei jedem Methodenaufruf wird automatisch ein neuer Formatter erzeugt
  • B) Der Singleton hält eine Formatter-Instanz für seine Lebensdauer, sofern kein Scoped Proxy oder ObjectProvider genutzt wird
  • C) Prototype-Scope wird still zu Singleton hochgestuft
  • D) Injection schlägt beim Startup immer fehl
Antwort & Erklärung

Richtige Antwort: B

Prototype-Beans in Singletons werden einmal bei Singleton-Erzeugung aufgelöst. Für Instanzen pro Nutzung: @Lookup, ObjectProvider oder Scoped Proxies.

Warum die anderen Optionen falsch sind:

  • A) Direkte Injection erzeugt den Prototype nicht bei jedem Methodenaufruf neu.
  • C) Scopes werden nicht still hochgestuft.
  • D) Injection gelingt, das Verhalten kann aber für per-Operation-Prototypes falsch sein.

Merksatz: „Prototype im Singleton = eine Instanz, außer mit ObjectProvider oder Proxy."

Weiterlernen: Buchkapitel

Frage 17​

Warum wird proxyMode = TARGET_CLASS auf diesem Request-Scoped-Bean genutzt?


@Bean
@Scope(value = WebApplicationContext.SCOPE_REQUEST, proxyMode = ScopedProxyMode.TARGET_CLASS)
public UserContext userContext() { return new UserContext(); }
  • A) Damit ein Singleton-Collaborator einen Proxy injizieren kann, der an die aktuelle Request-Instanz delegiert
  • B) Um den Bean zum Singleton zu machen
  • C) Um Dependency Injection zu deaktivieren
  • D) Um den Bean auf einem Hintergrundthread auszuführen
Antwort & Erklärung

Richtige Antwort: A

Scoped Proxies erlauben kürzer lebende Beans (Request/Session) in länger lebende Singletons zu injizieren. Der Proxy löst die korrekte Instanz pro Request auf.

Warum die anderen Optionen falsch sind:

  • B) Der Scope bleibt Request; der Proxy ändert ihn nicht zu Singleton.
  • C) Injection funktioniert über den Proxy.
  • D) Proxy-Mode ist unabhängig von Async-Threading.

Merksatz: „Scoped Proxy lässt Singletons Request-/Session-Beans sicher nutzen."

Weiterlernen: Buchkapitel

Frage 18​

Welches Callback-Interface erlaubt einem Bean, eigene Logik auszuführen, nachdem alle Properties gesetzt sind?

  • A) BeanFactoryPostProcessor
  • B) InitializingBean oder @PostConstruct-Methoden
  • C) Nur BeanDefinitionRegistryPostProcessor
  • D) ApplicationListener bedingungslos für jeden Bean
Antwort & Erklärung

Richtige Antwort: B

InitializingBean.afterPropertiesSet, custom Init-Methoden und @PostConstruct laufen nach abgeschlossener Dependency Injection und bevor der Bean genutzt wird.

Warum die anderen Optionen falsch sind:

  • A) BeanFactoryPostProcessor ändert Bean-Definitionen vor Instanziierung.
  • C) Registry Post-Processors arbeiten bei Definition-Registrierung.
  • D) ApplicationListener ist für Events, nicht generisches Init jedes Beans.

Merksatz: „Nach Properties setzen → @PostConstruct oder InitializingBean."

Weiterlernen: Buchkapitel

Frage 19​

Welche drei Annotationen setzt @SpringBootApplication zusammen?

  • A) @Configuration, @EnableAutoConfiguration und @ComponentScan
  • B) @SpringBootConfiguration, @EnableWebMvc und nur @EntityScan
  • C) @Controller, @Service und @Repository
  • D) @Import, @PropertySource und @Profile
Antwort & Erklärung

Richtige Antwort: A

@SpringBootApplication kombiniert @Configuration, @EnableAutoConfiguration und @ComponentScan (mit optionalen Attributen). Es ist der Einstiegspunkt für Boot Auto-Config und Component Discovery.

Warum die anderen Optionen falsch sind:

  • B) @EnableWebMvc optiert aus Boot-MVC-Auto-Config; nicht Teil der Standard-Triade.
  • C) Das sind Stereotypen, keine Meta-Annotationen von @SpringBootApplication.
  • D) Diese Annotationen gehören nicht zur Zusammensetzung.

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

Weiterlernen: Buchkapitel

Frage 20​

Was ist die Hauptrolle eines Spring-Boot-Starters wie spring-boot-starter-web?

  • A) Er definiert direkt jeden Bean in der Anwendung
  • B) Er bringt ein kuratiertes Set transitiver Dependencies für einen Feature-Bereich
  • C) Er ersetzt application.properties
  • D) Er deaktiviert Component Scanning
Antwort & Erklärung

Richtige Antwort: B

Starter sind Dependency-Deskriptoren, die kompatible Libraries auf den Classpath holen. Auto-Configuration erzeugt dann Beans, wenn Bedingungen passen.

Warum die anderen Optionen falsch sind:

  • A) Beans kommen aus User-Code und Auto-Config, nicht aus dem Starter-POM selbst.
  • C) Properties bleiben separate Konfiguration.
  • D) Scanning steuert @SpringBootApplication.

Merksatz: „Starter = Dependency-Bundle; Auto-Config = bedingte Beans."

Weiterlernen: Buchkapitel

Frage 21​

Ein custom DataSource-@Bean existiert bereits. Wie wirkt @ConditionalOnMissingBean auf die auto-konfigurierte DataSource-Erzeugung?

  • A) Boot erzeugt trotzdem eine zweite DataSource
  • B) Auto-Configuration tritt zurück und registriert keinen Default-DataSource-Bean
  • C) Der User-Bean wird gelöscht
  • D) User-Beans außerhalb des @SpringBootApplication-Packages werden ignoriert
Antwort & Erklärung

Richtige Antwort: B

@ConditionalOnMissingBean verhindert, dass Auto-Config einen Bean registriert, wenn der User bereits einen dieses Typs definiert hat — keine doppelten Primary-Beans.

Warum die anderen Optionen falsch sind:

  • A) Back-off vermeidet doppelte Beans.
  • C) User-Beans bleiben erhalten.
  • D) Package-Location befreit Beans nicht von Condition-Evaluation.

Merksatz: „OnMissingBean = Auto-Config tritt zurück, wenn User-Bean existiert."

Weiterlernen: Buchkapitel

Frage 22​

Wie kann ein Entwickler prüfen, welche Auto-Configuration-Klassen beim Startup gematcht haben oder nicht?


debug=true
# or
logging.level.org.springframework.boot.autoconfigure=DEBUG
  • A) Nur durch Dekompilieren der Spring-Boot-JARs
  • B) Debug-Logging aktivieren oder /actuator/conditions nutzen, wenn exponiert
  • C) Auto-Configuration-Entscheidungen sind nicht beobachtbar
  • D) @EnableWebMvc hinzufügen, um den Report zu drucken
Antwort & Erklärung

Richtige Antwort: B

Boot kann einen Conditions-Evaluation-Report drucken, wenn debug aktiv ist. Actuator exponiert /actuator/conditions für denselben Einblick in laufenden Apps.

Warum die anderen Optionen falsch sind:

  • A) Eingebautes Reporting existiert ohne Dekompilierung.
  • C) Conditions werden explizit geloggt oder über Actuator exponiert.
  • D) @EnableWebMvc ändert MVC-Config, nicht Condition-Reporting.

Merksatz: „Auto-Config debuggen mit debug=true oder Actuator /conditions."

Weiterlernen: Buchkapitel

Frage 23​

spring-boot-starter-data-jpa ist auf dem Classpath, aber keine Database-Driver-Dependency ist deklariert. Was ist typisch?

  • A) Hibernate verbindet automatisch mit einer eingebetteten Default-Produktionsdatenbank
  • B) Die Anwendung schlägt beim Startup fehl, weil ohne unterstützten Driver keine DataSource erzeugt werden kann
  • C) JPA funktioniert ohne Datenbank
  • D) Nur @WebMvcTest-Contexts sind betroffen
Antwort & Erklärung

Richtige Antwort: B

Der JPA-Starter liefert JPA/Hibernate-Support, aber keine Vendor-Driver. Ohne Driver (oder explizite DataSource-Config) kann DataSource-Auto-Configuration nicht erfolgreich sein.

Warum die anderen Optionen falsch sind:

  • A) Es gibt keine implizite Produktionsdatenbank.
  • C) JPA benötigt in typischen Setups eine DataSource.
  • D) Das betrifft den Haupt-ApplicationContext, nicht nur Web-Slice-Tests.

Merksatz: „JPA-Starter braucht eine Database-Driver-Dependency."

Weiterlernen: Buchkapitel

Frage 24​

Welche Property steuert üblicherweise, welche Actuator-Endpoints über HTTP exponiert werden?

  • A) management.endpoints.web.exposure.include
  • B) server.servlet.context-path.only
  • C) spring.jpa.show-sql
  • D) logging.pattern.console
Antwort & Erklärung

Richtige Antwort: A

management.endpoints.web.exposure.include (und exclude) bestimmt, welche Actuator-Endpoints auf dem Web-Port verfügbar sind — z. B. health, info, metrics.

Warum die anderen Optionen falsch sind:

  • B) Context Path beeinflusst URL-Prefix, nicht Endpoint-Auswahl.
  • C) show-sql ist JPA-Logging, nicht Actuator.
  • D) Logging-Pattern ist unabhängig von Endpoint-Exposure.

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

Weiterlernen: Buchkapitel

Frage 25​

Was steuert diese Einstellung?


management.endpoint.health.show-details=when_authorized
  • A) Ob Health-Details immer öffentlich erscheinen
  • B) Health-Detail-Sichtbarkeit nur für autorisierte Actuator-Requests, wenn konfiguriert
  • C) SQL-Logging für Health-Checks
  • D) Deaktiviert den Health-Endpoint vollständig
Antwort & Erklärung

Richtige Antwort: B

show-details regelt, wie viel Health-Information zurückgegeben wird. when_authorized verbirgt sensible Details vor anonymen Aufrufern und erlaubt autorisierten Nutzern mehr Detail.

Warum die anderen Optionen falsch sind:

  • A) always würde Details öffentlich zeigen; diese Einstellung ist restriktiver.
  • C) SQL-Logging ist separat.
  • D) Der Endpoint bleibt verfügbar; nur die Detail-Sichtbarkeit ändert sich.

Merksatz: „health show-details steuert, wie viel Health-Info Aufrufer sehen."

Weiterlernen: Buchkapitel

Frage 26​

Wann laufen CommandLineRunner-Beans in der Boot-Startup-Sequenz?

  • A) Bevor der ApplicationContext erzeugt wird
  • B) Nachdem der Context refreshed ist und die Anwendung gestartet hat
  • C) Nur bei HTTP-Request-Ankunft
  • D) Nur wenn Actuator /health aufgerufen wird
Antwort & Erklärung

Richtige Antwort: B

CommandLineRunner und ApplicationRunner laufen nach Context Refresh beim Anwendungsstart — nützlich zum Seeden von Daten oder Validieren der Konfiguration.

Warum die anderen Optionen falsch sind:

  • A) Der Context muss zuerst existieren.
  • C) Das sind Startup-Hooks, keine Request-Handler.
  • D) Actuator-Health-Checks triggern keine Runner.

Merksatz: „CommandLineRunner läuft nach Context Refresh beim Startup."

Weiterlernen: Buchkapitel

Frage 27​

Wie ändert spring.main.lazy-initialization=true die Bean-Erzeugung?

  • A) Alle Beans werden nie erzeugt
  • B) Singleton-Beans werden bei erstem Bedarf erzeugt statt eager beim Refresh
  • C) Nur Prototype-Beans werden lazy
  • D) Es deaktiviert Auto-Configuration
Antwort & Erklärung

Richtige Antwort: B

Lazy Initialization verzögert Singleton-Erzeugung bis zur ersten Abhängigkeit — schnellerer Startup, aber verzögerte Fehlererkennung.

Warum die anderen Optionen falsch sind:

  • A) Beans werden bei Bedarf weiterhin erzeugt.
  • C) Die Einstellung betrifft primär eager Singleton-Init.
  • D) Auto-Configuration läuft weiter.

Merksatz: „lazy-initialization = Singleton-Beans bei erster Nutzung erzeugen."

Weiterlernen: Buchkapitel

Frage 28​

Wo sind Auto-Configuration-Klassen in Spring Boot 3 für Imports gelistet?

  • A) Nur META-INF/spring.factories
  • B) META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports
  • C) WEB-INF/web.xml
  • D) application.yml spring.auto.import-Abschnitt
Antwort & Erklärung

Richtige Antwort: B

Boot 3 hat Auto-Configuration-Registrierung nach AutoConfiguration.imports unter META-INF/spring/ verschoben — Ersatz für spring.factories bei Auto-Config.

Warum die anderen Optionen falsch sind:

  • A) spring.factories ist Boot-2-Stil für Auto-Config.
  • C) web.xml wird nicht für Boot Auto-Config-Registrierung genutzt.
  • D) Kein solcher Standard-application.yml-Abschnitt registriert Auto-Config-Klassen.

Merksatz: „Boot 3 Auto-Config-Imports-Datei unter META-INF/spring/."

Weiterlernen: Buchkapitel

Frage 29​

Welche Rolle hat DispatcherServlet in Spring MVC?

  • A) Kompiliert nur JSP-Dateien
  • B) Front Controller, der Requests an Handler dispatcht und View Resolution oder Message Conversion koordiniert
  • C) Ersetzt den IoC-Container
  • D) Verwaltet Datenbanktransaktionen direkt
Antwort & Erklärung

Richtige Antwort: B

DispatcherServlet ist der Front Controller: Er mappt Requests via HandlerMapping, ruft Controller auf und löst Views auf oder schreibt Bodies über HttpMessageConverters.

Warum die anderen Optionen falsch sind:

  • A) JSP-Kompilierung ist container-spezifisch, nicht Kernrolle von DispatcherServlet.
  • C) ApplicationContext bleibt separat.
  • D) Transaktionen übernimmt Transaction Infrastructure, nicht DispatcherServlet.

Merksatz: „DispatcherServlet = Front Controller für Spring MVC."

Weiterlernen: Buchkapitel

Frage 30​

Welche Annotation bindet das {id}-URI-Segment an den Methodenparameter?


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

Richtige Antwort: B

@PathVariable mappt URI-Template-Variablen aus dem Pfad auf Handler-Methodenargumente.

Warum die anderen Optionen falsch sind:

  • A) @RequestParam bindet Query-Parameter.
  • C) @RequestBody bindet den HTTP-Body.
  • D) @MatrixVariable behandelt Matrix-Parameter, nicht Standard-{id}-Pfade.

Merksatz: „URI-Template-Variablen → @PathVariable."

Weiterlernen: Buchkapitel

Frage 31​

Was löst @Valid hier aus?


@PostMapping("/orders")
public ResponseEntity<OrderDto> create(@Valid @RequestBody CreateOrderRequest request) { }
  • A) Nur Datenbank-Constraint-Validierung
  • B) Bean Validation (Jakarta Validation) auf den Feldern des Request-Objekts
  • C) CSRF-Token-Verifikation
  • D) Automatische URL-Kodierung
Antwort & Erklärung

Richtige Antwort: B

@Valid triggert JSR-380-Validatoren auf dem Request-DTO. Verletzungen werden typischerweise zu 400-Responses mit @ControllerAdvice Exception Handling.

Warum die anderen Optionen falsch sind:

  • A) JPA-Validierung ist getrennt von MVC-Request-Validierung.
  • C) CSRF ist Aufgabe des Security-Filters.
  • D) URL-Kodierung ist unabhängig.

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

Weiterlernen: Buchkapitel

Frage 32​

Ein Handler wirft MethodArgumentNotValidException. Wo sollte sie in eine konsistente JSON-Fehlerantwort übersetzt werden?

  • A) @ControllerAdvice mit @ExceptionHandler
  • B) Nur in jedem Controller mit try/catch
  • C) Nur web.xml error-page-Einträge
  • D) application.properties
Antwort & Erklärung

Richtige Antwort: A

@ControllerAdvice zentralisiert Exception Handling über Controller hinweg und mappt Validierungs- und Business-Exceptions auf konsistente HTTP-Responses.

Warum die anderen Optionen falsch sind:

  • B) try/catch pro Controller dupliziert Logik.
  • C) Boot-Apps nutzen @ControllerAdvice statt web.xml für REST-Fehler.
  • D) Properties definieren kein Exception Mapping.

Merksatz: „Zentrale REST-Fehler → @ControllerAdvice + @ExceptionHandler."

Weiterlernen: Buchkapitel

Frage 33​

Wie nutzt Spring MVC @ResponseStatus auf einer Custom Exception?


@ResponseStatus(HttpStatus.NOT_FOUND)
public class OrderNotFoundException extends RuntimeException { }
  • A) Wird ignoriert, außer die Exception erweitert Exception
  • B) Kann die Exception einem HTTP-Status zuordnen, wenn sie aus einem Controller geworfen wird
  • C) Funktioniert nur auf Controller-Klassen
  • D) Aktiviert automatisch SQL-Rollback
Antwort & Erklärung

Richtige Antwort: B

@ResponseStatus auf einer Exception-Klasse signalisiert den HTTP-Status, wenn die Exception aus einem Handler propagiert — oft kombiniert mit @ControllerAdvice für Bodies.

Warum die anderen Optionen falsch sind:

  • A) Runtime Exceptions sind typisch für dieses Muster.
  • C) Es gilt für Exception-Typen, nicht nur Controller.
  • D) Transaction Rollback ist separates Thema.

Merksatz: „@ResponseStatus auf Exception → HTTP-Status beim Werfen."

Weiterlernen: Buchkapitel

Frage 34​

Content-Type application/json bei einem POST-Request wird von welcher Spring-MVC-Komponente verarbeitet?

  • A) Nur HandlerMapping
  • B) HttpMessageConverter wie MappingJackson2HttpMessageConverter
  • C) BeanFactoryPostProcessor
  • D) TransactionInterceptor
Antwort & Erklärung

Richtige Antwort: B

HttpMessageConverters deserialisieren Request-Bodies und serialisieren Response-Bodies. Der Jackson-Converter verarbeitet JSON für @RequestBody und @ResponseBody.

Warum die anderen Optionen falsch sind:

  • A) HandlerMapping wählt den Handler, nicht Body-Konvertierung.
  • C) BeanFactoryPostProcessor läuft beim Context Startup.
  • D) Transaktionen sind AOP-basiert, unabhängig von JSON-Parsing.

Merksatz: „JSON-Bodies → HttpMessageConverter (Jackson)."

Weiterlernen: Buchkapitel

Frage 35​

Ein Request kommt als GET /reports ohne page-Parameter an. Welchen Wert erhält page?


@GetMapping("/reports")
public List<ReportDto> list(@RequestParam(defaultValue = "0") int page) { }
  • A) null
  • B) 0
  • C) Startup schlägt fehl
  • D) Zufällige Seitennummer
Antwort & Erklärung

Richtige Antwort: B

defaultValue auf @RequestParam liefert den Wert, wenn der Query-Parameter fehlt.

Warum die anderen Optionen falsch sind:

  • A) Primitives können nicht null sein; Default greift.
  • C) Fehlende optionale Params mit Default führen nicht zum Binding-Fehler.
  • D) Spring nutzt den deklarierten Default, keine Zufallswerte.

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

Weiterlernen: Buchkapitel

Frage 36​

@RestControllerAdvice im Vergleich zu @ControllerAdvice auf einer Klasse, die auch @ResponseBody auf Methoden nutzt, ist primär:

  • A) Äquivalent für REST-JSON-Fehlerbehandlung bei passender Kombination
  • B) In Spring Boot illegal
  • C) Nur für JSP-Views
  • D) Ersetzt DispatcherServlet
Antwort & Erklärung

Richtige Antwort: A

@RestControllerAdvice entspricht @ControllerAdvice plus @ResponseBody — praktisch für REST-Exception-Handler, die JSON direkt zurückgeben.

Warum die anderen Optionen falsch sind:

  • B) Beide werden unterstützt.
  • C) REST Advice zielt auf HTTP-APIs, nicht JSP-Flows.
  • D) DispatcherServlet bleibt Front Controller.

Merksatz: „@RestControllerAdvice = @ControllerAdvice + @ResponseBody."

Weiterlernen: Buchkapitel

Frage 37​

Was generiert Spring Data JPA für ein Repository-Interface, das JpaRepository erweitert?

  • A) Nur eine SQL-Datei auf der Festplatte
  • B) Eine Runtime-Proxy-Implementierung mit CRUD- und Query-Method-Support
  • C) Eine konkrete Klasse, die manuell kompiliert werden muss
  • D) Eine JSP-Tag-Library
Antwort & Erklärung

Richtige Antwort: B

Spring Data erzeugt zur Laufzeit eine Proxy-Implementierung aus dem Repository-Interface — inklusive abgeleiteter Query-Methoden und Standard-JPA-Operationen.

Warum die anderen Optionen falsch sind:

  • A) Implementierung ist runtime-generiert, nicht nur statische SQL-Dateien.
  • C) Keine manuelle Implementierung für Standard-Repos nötig.
  • D) Unabhängig von JSP.

Merksatz: „Spring Data JPA Repos = runtime-generierte Implementierungen."

Weiterlernen: Buchkapitel

Frage 38​

Wie interpretiert Spring Data diesen Methodennamen?


List<Invoice> findByStatusAndDueDateBefore(String status, LocalDate date);
  • A) Als native SQL-Datei findByStatusAndDueDateBefore.sql
  • B) Als abgeleitete Query auf Entity-Properties status und dueDate
  • C) Als JPQL-String, der immer @Query erfordert
  • D) Als automatische Stored Procedure
Antwort & Erklärung

Richtige Antwort: B

Abgeleitete Query-Methoden parsen den Methodennamen in Queries gegen Entity-Attribute — hier Filter nach status und dueDate vor dem Datum.

Warum die anderen Optionen falsch sind:

  • A) Keine externe SQL-Datei nötig.
  • C) @Query ist optional, wenn Ableitung gelingt.
  • D) Procedure Mapping erfordert explizite Annotation.

Merksatz: „Abgeleitete Query-Methodennamen → Entity-Property-Prädikate."

Weiterlernen: Buchkapitel

Frage 39​

Warum ist orderRepository.save(order) hier möglicherweise unnötig?


@Transactional
public void cancelOrder(Long id) {
    Order order = orderRepository.findById(id).orElseThrow();
    order.cancel();
}
  • A) JPA persistiert Änderungen nie
  • B) Dirty Checking verfolgt Änderungen an managed Entities innerhalb der Transaktion
  • C) cancel() ruft automatisch save auf
  • D) Repositories committen jeden findById-Aufruf außerhalb von Transaktionen
Antwort & Erklärung

Richtige Antwort: B

Innerhalb einer Transaktion sind geladene Entities managed. Mutationen werden per Dirty Checking erkannt und beim Commit geflusht — ohne explizites save für bestehende Entities.

Warum die anderen Optionen falsch sind:

  • A) JPA persistiert managed Entity-Änderungen beim Flush/Commit.
  • C) cancel() ist Domain-Logik; Persistenz ist für managed Entities automatisch.
  • D) findById nimmt am aktuellen Persistence Context teil, wenn transactional.

Merksatz: „Managed Entity-Änderungen flushen per Dirty Checking in einer Transaktion."

Weiterlernen: Buchkapitel

Frage 40​

Default-Rollback-Verhalten für diese checked IOException:


@Transactional
public void importRows() throws IOException {
    rowRepository.saveAll(rows);
    throw new IOException("disk full");
}
  • A) Transaktion committet, weil checked Exceptions standardmäßig nicht rollbacken
  • B) Rollback immer bei allen Exceptions inklusive checked
  • C) Rollback nur bei Error-Typen
  • D) IOException wird von JPA ignoriert
Antwort & Erklärung

Richtige Antwort: A

Standardmäßig rollt Spring bei unchecked Exceptions und Error zurück. Checked Exceptions committen, sofern rollbackFor nicht konfiguriert ist.

Warum die anderen Optionen falsch sind:

  • B) Checked Exceptions sind standardmäßig keine Rollback-Trigger.
  • C) Unchecked RuntimeException rollt ebenfalls zurück.
  • D) IOException beeinflusst Commit/Rollback-Semantik, wird nicht von JPA ignoriert.

Merksatz: „Default Rollback = unchecked Exceptions und Error, nicht checked."

Weiterlernen: Buchkapitel

Frage 41​

Wann werden lines typischerweise mit LAZY Fetch geladen?


@OneToMany(mappedBy = "order", fetch = FetchType.LAZY)
private List<OrderLine> lines;
  • A) Beim Anwendungsstart für alle Orders
  • B) Wenn die lines-Collection innerhalb einer Session/Transaktion zugegriffen wird
  • C) Nie; LAZY bedeutet kein Laden
  • D) Nur während Component Scanning
Antwort & Erklärung

Richtige Antwort: B

Lazy Associations laden beim ersten Zugriff, solange der Persistence Context offen ist. Zugriff außerhalb einer Transaktion führt zu LazyInitializationException.

Warum die anderen Optionen falsch sind:

  • A) Lazy lädt nicht alles eager beim Startup.
  • C) Lazy verzögert Laden bis zum Zugriff.
  • D) Component Scanning ist unabhängig.

Merksatz: „LAZY lädt bei Zugriff; offener Persistence Context nötig."

Weiterlernen: Buchkapitel

Frage 42​

Das N+1-Query-Problem in JPA tritt oft auf, wenn:

  • A) @Transactional auf Services genutzt wird
  • B) N Parent-Entities geladen werden und dann pro Child-Association ein Query ausgelöst wird
  • C) Nur abgeleitete Query-Methoden genutzt werden
  • D) Nur H2 in Tests genutzt wird
Antwort & Erklärung

Richtige Antwort: B

N+1 entsteht, wenn ein Query Parents lädt und lazy Child-Zugriff pro Parent ein zusätzliches Query auslöst — außer mit Fetch Joins oder Batch Fetching.

Warum die anderen Optionen falsch sind:

  • A) Transaktionen verursachen N+1 nicht von sich aus.
  • C) Abgeleitete Queries sind unabhängig von Association-Fetch-Patterns.
  • D) N+1 kann mit jeder Datenbank auftreten.

Merksatz: „N+1 = ein Query für Parents + einer pro Child bei lazy Zugriff."

Weiterlernen: Buchkapitel

Frage 43​

REQUIRES_NEW Propagation bedeutet:


@Transactional(propagation = Propagation.REQUIRES_NEW)
public void writeAudit() { auditRepository.save(entry); }
  • A) Immer der Caller-Transaktion beitreten
  • B) Caller-Transaktion suspendieren und eine neue unabhängige Transaktion starten
  • C) Nie eine Transaktion nutzen
  • D) Nur Read-only-Optimierung
Antwort & Erklärung

Richtige Antwort: B

REQUIRES_NEW suspendiert eine bestehende Transaktion, öffnet eine neue und committet unabhängig. Rollback der inneren Transaktion beeinflusst die äußere nicht.

Warum die anderen Optionen falsch sind:

  • A) REQUIRED tritt bei bestehender Transaktion bei; REQUIRES_NEW ist unabhängig.
  • C) Es nutzt weiterhin eine Transaktion — eine neue.
  • D) readOnly ist separates Attribut.

Merksatz: „REQUIRES_NEW = neue unabhängige Transaktion; äußere suspendiert."

Weiterlernen: Buchkapitel

Frage 44​

Ein anderer Bean ruft outer() auf. Warum läuft inner() möglicherweise nicht transactional?


public void outer() { inner(); }

@Transactional
public void inner() { repository.save(entity); }
  • A) @Transactional funktioniert nie auf Services
  • B) outer() ruft inner() via this auf und umgeht den Proxy
  • C) save läuft immer ohne Transaktionen
  • D) Repository-Saves starten nur eigene mandatory Transaktionen
Antwort & Erklärung

Richtige Antwort: B

Self-Invocation innerhalb derselben Klasse umgeht den Spring-AOP-Proxy — @Transactional auf inner() greift nicht, wenn von outer() aufgerufen.

Warum die anderen Optionen falsch sind:

  • A) @Transactional funktioniert, wenn Aufrufe über den Proxy laufen.
  • C) Persistence braucht Context; Proxy-Bypass ist die Falle.
  • D) Das Problem ist Proxy-Eintritt, nicht nur Repository-Transaktionen.

Merksatz: „Same-Class-Aufrufe umgehen Proxy → @Transactional greift evtl. nicht."

Weiterlernen: Buchkapitel

Frage 45​

In der Spring-Security-Filter-Chain-Architektur: Wo findet Authentication typischerweise relativ zu Authorization statt?

  • A) Authorization immer vor Authentication
  • B) Authentication stellt Identität her, bevor Authorization Zugriff prüft
  • C) Sie sind derselbe Filter
  • D) Beides läuft nicht für REST-APIs
Antwort & Erklärung

Richtige Antwort: B

Security-Filter authentifizieren (wer bist du) und autorisieren dann (was darfst du). Authentication muss den SecurityContext füllen, bevor Access Decisions fallen.

Warum die anderen Optionen falsch sind:

  • A) Access Decisions brauchen zuerst einen authentifizierten Principal.
  • C) Separate Filter mit unterschiedlichen Aufgaben.
  • D) REST-APIs nutzen weiterhin die Security-Filter-Chain, wenn aktiviert.

Merksatz: „Zuerst authentifizieren, dann autorisieren."

Weiterlernen: Buchkapitel

Frage 46​

Was bedeutet permitAll() auf /public/**?


http.authorizeHttpRequests(auth -> auth
    .requestMatchers("/public/**").permitAll()
    .anyRequest().authenticated());
  • A) Erfordert ADMIN-Rolle
  • B) Erlaubt Zugriff ohne Authentication für passende Pfade
  • C) Deaktiviert HTTPS
  • D) Aktiviert CSRF-Schutz nur auf /public
Antwort & Erklärung

Richtige Antwort: B

permitAll gewährt uneingeschränkten Zugriff auf gematchte Requests ohne authentifizierten Principal.

Warum die anderen Optionen falsch sind:

  • A) ADMIN würde hasRole nutzen.
  • C) Transport Security ist separat.
  • D) CSRF-Regeln werden woanders konfiguriert.

Merksatz: „permitAll = keine Authentication für gematchte Pfade nötig."

Weiterlernen: Buchkapitel

Frage 47​

Best Practice für Passwort-Speicherung in Spring Security:

  • A) Plain-Text PasswordEncoder
  • B) BCryptPasswordEncoder oder delegating Encoder mit starkem Hashing
  • C) MD5 ohne Salt
  • D) Nur Base64-Kodierung
Antwort & Erklärung

Richtige Antwort: B

Spring Security empfiehlt starkes adaptives Hashing wie BCrypt via PasswordEncoder — nie Plain Text oder schwache Hashes.

Warum die anderen Optionen falsch sind:

  • A) Kein Plain-Text-Encoder ist sicher.
  • C) MD5 ist ungeeignet für Passwort-Speicherung.
  • D) Base64 ist Kodierung, kein Hashing.

Merksatz: „Passwörter mit BCrypt PasswordEncoder speichern, nicht im Klartext."

Weiterlernen: Buchkapitel

Frage 48​

Eine stateless JWT REST API sollte typischerweise:

  • A) Session-Erzeugung für jeden Request aktivieren
  • B) CSRF deaktivieren, weil Browser JWTs nicht wie Cookies bei klassischen Form-Posts auto-submitten
  • C) JWT nur in server HttpSession speichern
  • D) Alle Authorization-Regeln entfernen
Antwort & Erklärung

Richtige Antwort: B

Stateless Token APIs deaktivieren oft CSRF, weil CSRF cookie-basierte Session-Auth zielt. JWT im Authorization-Header ist ein anderes Threat Model.

Warum die anderen Optionen falsch sind:

  • A) Stateless Design vermeidet Server-Sessions pro Request.
  • C) JWT-Stateless-Pattern vermeidet HttpSession für Auth-Token.
  • D) Authorization bleibt erforderlich.

Merksatz: „Stateless JWT APIs deaktivieren oft CSRF; Endpoints weiter autorisieren."

Weiterlernen: Buchkapitel

Frage 49​

Wann wird diese Authorization für Spring-MVC-Beans durchgesetzt?


@PreAuthorize("hasRole('ADMIN')")
public void deleteUser(Long id) { }
  • A) Nur zur Compile-Zeit
  • B) Bei Methodenaufruf via Method-Security-AOP nach @EnableMethodSecurity
  • C) Nur in der Datenbankschicht
  • D) Nur für statische Methoden
Antwort & Erklärung

Richtige Antwort: B

@PreAuthorize wird von Method-Security-Interceptors um Bean-Methodenaufrufe evaluiert, wenn Method Security aktiviert ist.

Warum die anderen Optionen falsch sind:

  • A) Enforcement ist zur Laufzeit via AOP.
  • C) Es schützt die Service-Methode, nicht SQL direkt.
  • D) Instanzmethoden auf Spring Beans werden advised.

Merksatz: „@PreAuthorize wird zur Laufzeit per Method-Security-AOP durchgesetzt."

Weiterlernen: Buchkapitel

Frage 50​

CORS-Konfiguration in Spring Security/Boot adressiert:

  • A) Cross-Origin-Browser-Requests und Preflight-OPTIONS-Handling
  • B) SQL-Injection-Prävention
  • C) Passwort-Hashing
  • D) JPA Lazy Loading
Antwort & Erklärung

Richtige Antwort: A

CORS steuert, welche Browser-Origins APIs cross-origin aufrufen dürfen — inklusive Preflight OPTIONS für non-simple Requests.

Warum die anderen Optionen falsch sind:

  • B) SQL Injection ist Input-/Parametrisierungs-Thema.
  • C) Passwörter nutzen PasswordEncoder.
  • D) JPA Lazy Loading ist Persistenz-Thema.

Merksatz: „CORS = Cross-Origin-Browser-Zugriffsregeln und Preflight."

Weiterlernen: Buchkapitel

Frage 51​

@WebMvcTest lädt primär:

  • A) Vollständigen Application Context inklusive aller Repositories und Scheduler
  • B) Web-Layer-Slice: MVC, Jackson, oft @Controller unter Test mit gemockten Collaborators
  • C) Nur JPA-Entities ohne Controller
  • D) Nur Production-Database-Migrationen
Antwort & Erklärung

Richtige Antwort: B

@WebMvcTest ist ein schmaler Slice für Controller-Tests mit MockMvc, kein Full-Stack-Integrationstest.

Warum die anderen Optionen falsch sind:

  • A) Full Context ist @SpringBootTest.
  • C) JPA-Slice ist @DataJpaTest.
  • D) Flyway/Liquibase laufen ggf. in Integrationstests, nicht im Web-Slice-Default.

Merksatz: „@WebMvcTest = MVC-Slice + MockMvc, kein Full Context."

Weiterlernen: Buchkapitel

Frage 52​

Warum wird hier @MockBean genutzt?


@WebMvcTest(OrderController.class)
class OrderControllerTest {
    @MockBean OrderService orderService;
}
  • A) Um eine fehlende Dependency im Test-ApplicationContext durch einen Mockito-Mock-Bean zu ersetzen
  • B) Um Production-Database-Zugriff zu aktivieren
  • C) Um MockMvc zu deaktivieren
  • D) Um Tests ohne Spring auszuführen
Antwort & Erklärung

Richtige Antwort: A

@MockBean registriert einen Mockito-Mock im Spring-Test-Context und ersetzt oder ergänzt einen Bean, den der Web-Slice braucht.

Warum die anderen Optionen falsch sind:

  • B) Web-Slice vermeidet echte Persistenz standardmäßig.
  • C) MockMvc funktioniert weiter.
  • D) @WebMvcTest nutzt weiterhin Spring Test Context.

Merksatz: „@MockBean bringt einen Mock in den Spring-Test-Context."

Weiterlernen: Buchkapitel

Frage 53​

@DataJpaTest konfiguriert typischerweise automatisch:

  • A) Vollständige Spring-Security-Filter-Chain und alle Controller
  • B) In-Memory-DataSource, JPA, TestEntityManager und Repository unter Test
  • C) Nur MockMvc
  • D) Nur @Scheduled Tasks
Antwort & Erklärung

Richtige Antwort: B

@DataJpaTest fokussiert JPA-Komponenten mit eingebetteter Datenbank und TestEntityManager für Persistenztests.

Warum die anderen Optionen falsch sind:

  • A) Security und Controller sind vom JPA-Slice ausgeschlossen.
  • C) MockMvc gehört zu Web-Tests.
  • D) Scheduling ist nicht JPA-Slice-Fokus.

Merksatz: „@DataJpaTest = JPA + embedded DB + TestEntityManager."

Weiterlernen: Buchkapitel

Frage 54​

@SpringBootTest im Vergleich zu Slice-Tests:

  • A) Lädt den vollständigen Application Context (oder nahezu vollständig) für Integrationstests
  • B) Ist immer schneller, weil weniger geladen wird
  • C) Kann @Autowired nicht nutzen
  • D) Deaktiviert alle Beans
Antwort & Erklärung

Richtige Antwort: A

@SpringBootTest startet den vollen Application Context — geeignet für Integrationstests über Layer hinweg.

Warum die anderen Optionen falsch sind:

  • B) Full Context ist schwerer, nicht leichter.
  • C) @Autowired funktioniert in SpringBootTest.
  • D) Es lädt echte Beans, sofern nicht gemockt.

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

Weiterlernen: Buchkapitel

Frage 55​

Dieser @WebMvcTest-Test verifiziert primär:


@Test
void delegatesToService() {
    when(orderService.find(1L)).thenReturn(Optional.of(dto));
    mockMvc.perform(get("/orders/1")).andExpect(status().isOk());
}
  • A) Datenbank-Constraint-Korrektheit
  • B) HTTP-Mapping und Controller-Delegation mit gemocktem Service
  • C) Production-Actuator-Health
  • D) Git-Commit-Hooks
Antwort & Erklärung

Richtige Antwort: B

MockMvc testet die Web-Schicht, während @MockBean Collaborators isoliert — Mapping, Status und JSON ohne Full Stack.

Warum die anderen Optionen falsch sind:

  • A) Datenbank gehört zu @DataJpaTest oder Integrationstests.
  • C) Actuator ist separates Test-Thema.
  • D) Unabhängig von MVC-Tests.

Merksatz: „MockMvc + @MockBean testet Controller-Verdrahtung isoliert."

Weiterlernen: Buchkapitel

Frage 56​

@Mock versus @MockBean: zentraler Unterschied?

  • A) @Mock ist reines Mockito ohne Spring Context; @MockBean registriert Mock im Spring-Test-Context
  • B) Sie sind immer identisch
  • C) @MockBean funktioniert nur in der Hauptanwendung
  • D) @Mock lädt die volle Spring-Boot-App
Antwort & Erklärung

Richtige Antwort: A

@Mock ist für plain Unit Tests. @MockBean integriert Mockito-Mocks in Spring TestContext und ersetzt Container-Beans.

Warum die anderen Optionen falsch sind:

  • B) Spring-Context-Integration unterscheidet sich.
  • C) @MockBean ist für Tests.
  • D) @Mock startet kein Spring.

Merksatz: „@Mock = nur Mockito; @MockBean = Mock im Spring-Test-Context."

Weiterlernen: Buchkapitel

Frage 57​

In Spring AOP ist ein Join Point typischerweise:

  • A) Eine Methodenausführung auf einem Spring-verwalteten Bean
  • B) Jede Bytecode-Zeile in der JVM
  • C) Nur Database-Trigger-Ausführung
  • D) Nur statische Initializer-Blöcke
Antwort & Erklärung

Richtige Antwort: A

Spring AOP unterstützt Method-Execution-Join-Points auf Spring Beans. Es ist kein vollständiges AspectJ-Weaving aller Join Points standardmäßig.

Warum die anderen Optionen falsch sind:

  • B) Spring AOP ist method-interception-basiert auf Beans.
  • C) Database Triggers liegen außerhalb Spring AOP.
  • D) Statische Blöcke werden standardmäßig nicht advised.

Merksatz: „Spring-AOP-Join-Point = Methodenausführung auf einem Spring Bean."

Weiterlernen: Buchkapitel

Frage 58​

Was steuert @Around Advice?


@Aspect
@Component
public class TimingAspect {
    @Around("execution(* com.example.service..*(..))")
    public Object time(ProceedingJoinPoint pjp) throws Throwable {
        long start = System.nanoTime();
        Object result = pjp.proceed();
        // log duration
        return result;
    }
}
  • A) Nur Code vor der Methode
  • B) Umschließt den Join Point und kann Code vor/nach ausführen und proceed() steuern
  • C) Nur nach erfolgreichem Return
  • D) Nur ungefangene Exceptions
Antwort & Erklärung

Richtige Antwort: B

@Around Advice umschließt den Join Point. proceed() muss aufgerufen werden, um das Target zu invoken — Argumente, Rückgabewert und Exceptions können modifiziert werden.

Warum die anderen Optionen falsch sind:

  • A) Nur-vorher ist @Before Advice.
  • C) Nach Return ist @AfterReturning.
  • D) Exception Handling kann @AfterThrowing nutzen.

Merksatz: „@Around umschließt die Methode und ruft proceed() zum Weiterlaufen auf."

Weiterlernen: Buchkapitel

Frage 59​

@EnableAsync auf einer Configuration-Klasse aktiviert:

  • A) Nur synchrone Methodenausführung
  • B) Proxy-basierte asynchrone Ausführung für @Async-Methoden via Task Executor
  • C) Automatisches HTTP-Caching
  • D) Nur JPA Second-Level-Cache
Antwort & Erklärung

Richtige Antwort: B

@EnableAsync registriert Infrastruktur, die @Async-Methoden auf einem Task-Executor-Thread statt im Caller-Thread ausführt.

Warum die anderen Optionen falsch sind:

  • A) Es aktiviert Async, nicht Sync-only.
  • C) HTTP-Caching ist separat.
  • D) JPA-Cache ist Persistenz-Konfiguration.

Merksatz: „@EnableAsync + @Async führt Methoden auf Executor-Threads aus."

Weiterlernen: Buchkapitel

Frage 60​

Spring Application Events über ApplicationEventPublisher sind standardmäßig:

  • A) Automatisch in der Datenbank persistiert
  • B) Synchron an Listener im Publisher-Thread geliefert, sofern Listener nicht @Async nutzen
  • C) Per HTTP an alle Clients gesendet
  • D) Ignoriert, außer der Publisher ist ein @Controller
Antwort & Erklärung

Richtige Antwort: B

Standard-Event-Delivery ist synchron im Caller-Thread. @Async-Listener mit aktiviertem Async können in Hintergrundthreads verarbeiten.

Warum die anderen Optionen falsch sind:

  • A) Events sind standardmäßig in-memory.
  • C) Events sind keine HTTP-Broadcasts.
  • D) Jeder Bean kann Events publizieren und empfangen.

Merksatz: „Spring Events sind standardmäßig synchron im Publisher-Thread."

Weiterlernen: Buchkapitel

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